First reason, from my friend Steve: tests can’t make a bad design into a good design.

I can give a concrete example from my past here: I designed a 32bit integer divide algorithm using floating-point and fixed-point instructions. There was no way I could have written a set of tests for that algorithm before creating the algorithm. Testing the algorithm required the help of “math people” and carefully chosen test cases based on the way that the algorithm worked. Random selections from the 2**64 possible test cases would not have been useful in validating the algorithm.

Going in the other direction, you can almost certainly gin up a broken piece of code to pass any test suite. Try it.

Second reason: Until your code structure and APIs are semi-solid, test code is pure baggage.

Sure, you will catch some regressions with early test code. But every time you need to refactor or change your APIs, you need to rewrite all that test code. Early on, you need the freedom to change-up the structure based on the initial experience of real programming against your APIs. A significant percentage of getting APIs right is applying the learnings gleaned from early use of those APIs in actual use-cases. After the APIs/structure “feels good”, go ahead and start adding test code. BTW, writing test code does NOT count as “using an API”.

Test is massively important, but it isn’t the starting point. Do good design, then get enough of the API implemented to start learning from use. When the time is right, start coding up the test suites.