When constructing prototypes, should we also create appropriate unit tests as if we were writing production code? Would it make a difference if we knew in advance that the code was or wasn't going to be re-used for the final solution?

  • 1
    Unit tests are programmatic specifications of exactly what your application should do. It's not likely you would know this in a prototype, right? Can you give a specific example of what sort of prototype you have in mind?
    – bzlm
    Aug 25, 2011 at 7:04
  • @bzlm Do you have any reference for your quote?
    – Nicolas
    Aug 25, 2011 at 7:25
  • @nicolas, it's not a quote, it's a cornerstone of test-driven development in specific and unit testing in general. Do you have much experience with unit testing?
    – bzlm
    Aug 25, 2011 at 7:26
  • Yes, i have a little experience in unit testing, it's the word "application" that makes me uncomfortable here.
    – Nicolas
    Aug 25, 2011 at 7:34
  • This is a question of the type "should we always wear shoos when going outside?" I mean: do whatever is helpful for you in your specific situation, and avoid it when it doesn't help. There isn't a rule for everything. Aug 25, 2011 at 12:07

6 Answers 6


Even in a prototype, it's good to know what each part is supposed to do. When you write a prototype, you still want to understand what's wrong with your code when something doesn't work as expected. Unit tests are the best solution to figure it out.

Furthermore, unit tests are a great way to clarify your mind about what each part of your prototype is supposed to do and most of the time, it can serve as base code to write the tests when you write the production version.

But... It really depends of the size of your project and of its complexity. For a small project it might be easier to go ahead and make things works.


I usually don't write unit tests of prototypes, cause I don't reuse prototype code. If I knew that the prototype code would be promoted to production code at a later stage, I would definitely write unit tests up front.


This depends on a number of things, including the expected longevity of the prototype environment.

For example, it is not so uncommon to prototype user interfaces for vending machines in flash (or similar technologies) and have them reimplemented in C or something to run on the actual machine.
In such cases the prototype itself has a long life during which it is subject to change, because it is used for user interaction testing and prototyping of interface enhancements. Given that in a scenario like this, drastic changes are to be expected, unit tests are very helpful.

Of course, if you write a piece of code to for example get a rough idea about how a software/hardware architecture will perform/scale by throwing some simulated user input at it, to determine whether it could suit your requirements (for example when comparing different data stores by filling them with loads of data and running frequently expected queries on them to determine which to choose), you will probably throw vast parts of the code away once you have your numbers.


I don't write unit tests, unless the code is about solving a complex issue with complex requirements. In that case, I write a couple tests. I try to rely on existing/tested modules as much as possible to avoid re-inventing the wheel.

It is only later, when the decision is taken to move the prototype into production that I fully test it with a complete set of unit tests.


Unit testing is about product and code quality. If you want to be sure about your product quality, use unit tests.


What is the purpose of creating a prototype, rather than version 0.1 of the application? It should be to provide some information about the application domain or an algorithm that you lack. The quality of the information you get can not be better than the quality of the prototype itself, so you should ask yourself:

If I do not create unit tests, will the resulting prototype have enough quality for me to rely on the information I get from it?

In most cases I beleive the answer is "no".

  • Had to downvote, prototype is a prototype, just a throwaway code. It's a bad practice to use prototype into production code. Please refer to the book: Code Complete, chapter "Experimantal Prototyping"
    – andrew.fox
    Jan 7, 2016 at 12:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.