I’m not sure how ‘tests first’ works and I’d like to hear arguments about when and why one would take this approach.
I hear that it’s often recommended to write tests and mock things before writing a single line of implementation. However, I can’t help but think that it doesn’t fit every situation. For instance, say I’m making a prototype and I’m not sure how everything is going to work yet. So I just start finding examples of each step that I think I need and throwing them into my code. At the end I have a proof of my theory and it didn’t take that long. This is essentially ‘my test’. It’s not a unit test, but it is a test (most likely it’s a console app).
This is pretty much how I work. I think about what I want to do and try to do it. If it works then I eventually go back and write unit tests so that I can trap regression. Is this different than what you’re ‘supposed to do’?
The over-arching rule is: Do the riskiest items first.
Doing the test-cases first is, implicitly, arguing that the riskiest part of the coding is miscommunications and misunderstandings of the interfaces and behaviour of the objects that are being created.
For many projects, that may well be true, and TDD is very appropriate in those cases.
However, in many projects that is not the case, and applying TDD in those cases is a poor choice.
If your highest risk is usability, stop futzing about with unit tests and do some UI prototyping.
If your highest risk is performance, do some performance prototypes first, and don’t worry about interfaces.
This list goes on.
Doing the risky items first has many advantages:
Projects that are inevitably doomed die early, before many resources are wasted.
Projects that are in trouble but are salvageable get the project management focus early, when it can do some good.
The business side of your organization will value a project higher when it has a low risk of failure; there’s less chance that it will be cancelled early unnecessarily.