Reflections on writing tests before or after writing a method
I was chatting with Joël and was trying to improve my approach in writing tests and code, the philosophy, key things to consider, and reach greater finesse. Here some of the outcomes:
TDD, write tests before writing the method
-
As a developer and a human, it makes me feel more confident about the code I am about to write, that I really understand it and there is no guess component in it.
-
I am thinking of all the possible scenarios and the edge cases as well.
On this, also see this great article by Joël
Backfill the tests after I already wrote the method
- As mentioned above it gives me more uncertainty:
- “I think it should work like that…”;
- “In theory this object should exist at this point…” which is not always true;
- And overall the tendency is to have a more complex test setup, sometimes declaring more objects than necessary, creating them instead of building or stubbing them, all aspects that will lead to less elegant and performant code in the end.
-
It forces me to think in terms of “happy path” and “sad path” rather than testing all the cases. Namely it is easy to forget about edge cases as mentioned above on point 2.
- I may write a test that would pass no matter what (hint: even if you end up in this scenario, do not despair, when the test is green, try to assert the opposite and watch it fails with satisfaction) Related to this, Joël suggested the deletion of lines of code and observe the behavior, as there could be what he called “dead code”.)