Someone asked me, what's the trade-off? At what point do you start writing tests?
For me, it's at one of a few points:
- Somewhere between 100-200 lines of code I start feeling the need for tests
- When I start feeling unclear in my head, I reach to tests to make them clear
- If someone wants to work with me, tests instantly become mandatory
- When I come back to some code after a while
- When I notice my first bug
What about you? Do you always do TDD? Do you have any rules-of-thumb for when you do?
4 comments:
"Before anything" :-) (I wish I would!)
Whenever I have to show things I wrote to the wider world.
When a program gets big enough that I have to perform more than 2 manual actions (commands, clicks, hits to an URL).
If I can get ~100% coverage and instant repeatability by simply re-running the program (script) then there's no point to an automated test suite; the program is effectively testing itself. But, once I need to do five, six, or seven things in order to start testing it comprehensively, I will start forgetting some of the steps, doing some of them wrong, or occasionally skipping them, and maintenance difficulties set in.
Pretty much any non-trivial program fits into this category, of course. But many trivial programs of the "rename a bunch of audio files" variety are easy to test just by having some stub input and re-running it until the output looks right.
Usually not at the right time.
Sometimes I start too early (before I write my first line of code) and it slows down my progress too much, causing me to get distracted before I have a working initial version that would keep me interested.
Sometimes I start too late and that means I have to do a lot of refactoring and after-the-fact writing of tests. Often this is at a point where I have spent more time then necessary in a debugger trying to figure out which layer of my code is buggy.
Post a Comment