Passionate developer in Java and Scala. And sometimes, something else. A few months per year, someone calls me "professor". CoFounder of Scala By The Lagoon @scalagoon
The TDD cycle needs another step: Think, before writing a failing test. That's clearly stated in the C2 Wiki where TDD was first defined, but somehow everyone forgets that step.
In compiled languages you use your tests to design your API: so, you describe in your tests how your API will look and feel, and then before running it for red, you write enough structure to make it compile.
In strongly-typed languages (Scala, Haskell) you may even design types that match so well the domain that if a program compiles, it is probably correct; the types prohibit you to even represent an invalid state of the system. If you can exclude most errors because you can't write them in code (the compiler blocks you when it checks the types), you can afford to write much less tests.
The TDD cycle needs another step: Think, before writing a failing test. That's clearly stated in the C2 Wiki where TDD was first defined, but somehow everyone forgets that step.
In compiled languages you use your tests to design your API: so, you describe in your tests how your API will look and feel, and then before running it for red, you write enough structure to make it compile.
In strongly-typed languages (Scala, Haskell) you may even design types that match so well the domain that if a program compiles, it is probably correct; the types prohibit you to even represent an invalid state of the system. If you can exclude most errors because you can't write them in code (the compiler blocks you when it checks the types), you can afford to write much less tests.
I also suggest you to view 7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development: it's a short, but brillant piece of thather that will give you another perspective on this.