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?
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".