[fixermark]

The most significant downside is opportunity cost; all code is eventually throwaway code, and if you are doubling your authoring burden by writing code and tests on a throwaway prototype, you are iterating half as fast as you could be.

But in my personal experience, most programmers err heavily on the side of failing to test thoroughly something that will become a long-term solution, not on the side of over-testing their throwaways.

[jeremysmyth]

It sounds like you write your tests based on the code you write rather than its expected behaviour.

You can write a good set of tests when you know the initial requirements, and not all requirements iterate at the same rate as the code. As you learn new requirements, you write new tests. The old ones don't go away (nor do the early requirements if they're good), even if you completely replace the implementing code.

[fixermark]

> You can write a good set of tests when you know the initial requirements

Throwaway prototypes are part of the requirement discovery process.