This question came up again recently. Good software engineering is rigorous about tests because they reduce bugs both in the code’s present state and with code changes, ultimately improving quality and speed.
When you are at the early stages of an idea, just trying to test out whether it holds water, should you bother with tests at all? Speed of learning is your goal, not engineering rigor, but that does not negate the relevance of tests.
You must make a judgement call based on the complexity and duration of your experiment.
When thinking about code tests, ask yourself:
A. will it take you more than a few hours to write the code? if so, it can be good to add unit tests or you might find yourself less productive overall. This is a good rule of thumb from Peter Bell
B. do you expect this code to stick around for more than a short period? if it is going to stick around, think through what level of testing will help you pivot the code base faster
I have suffered from brittle test suites (especially on the front-end) that made change extremely painful, and seen the opposite, where bug hunting in the dark excessively slowed down the process. Finding the right balance is key.
And remember, code tests never negate the requirement of trying the application as a human being to see if it does what you expect. Your experiments and MVPs do need to be “viable” to be effective learning tools — but remember that they only need to viable in as much as you hit your learning goal.