For some reason, one of the small joys in life as a developer seems to be writing code and not writing tests. It almost seems like a form of rebellion against the 'rule book', and you'll get laughs if you mention the word prototyping and testing in the same conversation. I'm all for writing some down right hacky code to quickly try something out, but I'm also all for writing tests for some of that code. I know you probably think I've lost my mind, but stick with me just a little bit longer while I explain this concept.

tl;dr

• Manual testing is too slow as your prototype grows
• Set up the ability to run unit tests with your project very early on
• Be comfortable treating unit tests as you would scrap paper
• Benefit with faster prototyping and learning how to test earlier on

What is testing used for anyway?

Tests exist to validate that some piece of logic is doing what we expect it to do. Sometimes these tests can be executed programmatically, other times we simply run up the program and manually test it. We'll generally lean towards the latter when building a prototype, we'll hack out some code, spin up the program, see if it works or not, and then rinse and repeat. So when it comes down to it, we already are "testing" our prototype code, just not necessarily in a nice repeatable manner.

It's fast to test manually, until it's not

So there you are, hacking out some premium code for your prototype and spinning it up every now and then to see if it works. For your first few lines of code, the turnaround time of spinning up the program to manually test it is likely pretty quick. A few lines of code doesn't usually take long to execute, and with so few logical paths to follow, it's pretty straight forward to manually assert if it works or not. As the code size and the number of logic paths grow, this process of manually validating gets slower and slower. This is around the point that I used to find myself getting increasingly frustrated at how long it takes to validate that a tiny change is working or not.

Treating unit tests as scrap paper

What I find I'm doing more and more these days is setting up my projects to have a way to run unit tests very early on. At this point, I'm not really in a hurry to unit test everything, instead, I use unit tests as I would use scrap paper. I scribble down some code to quickly test out something in the program, play around until it works as I expect, and feel very comfortable scrunching it up and throwing it away. If I feel that the test will continue to add value in the future (as a spec for the non-prototype version or to help with future changes in that area of the code base) I'll keep it around, otherwise off to the recycling bin with it!

The usefulness of this approach is that I can quickly test parts of my code in isolation while not feeling it necessary to make the tests perfect. Writing clean tests takes time, and during the prototyping phase you're usually looking to validate an idea as quickly as possible. By taking this approach, you get the benefit of being able to quickly test your code without having to spend extra time perfecting and maintaining a test suite.

Increase your understanding early on

One of the big upsides I've found with this approach is that when I am prototyping in a new language or with a new library, I am learning how to write tests for it very early on. This is enormously useful when it comes time to write the production friendly code, as I don't have to waste additional time at that stage figuring out how to write tests.

You might also find that it's very slow and difficult to write tests for the language or library you've chosen. This is something that's very useful to figure out early on, as you've likely not yet become too attached to the language or library and still have the opportunity to try out something else that is hopefully more test friendly.

All in all, a faster way to prototype

If you follow this approach, you get the best of both worlds for prototyping, you can still write hacky code quickly to validate our ideas and you can also validate your hacky code quickly, without having to spin up the entire program every time.

Give it a go and share your thoughts!