A great post from Ian Cartwright, on how to treat test code. You’ve probably guessed it, it’s not different than other production code.
A few comments on the traps of tests he lists:
- Cut and Paste: We all know cutting and pasting code is a maintenance monster ready to awake. With tests, however, I’m not completely against doing this. For me it’s about readability. The test need to convey what it’s testing. I’d like to read the test top to bottom and understand what it does. There’s obviously a middle ground. You don’t need all copies, and you don’t need something very concise but not readable. Do what you feel you can live with.
- Bloated Setup: Ian describes solutions that begin with the production code. Obviously, if you used good practices, have decoupled code, use a DI container and so on, you’ll have clearer unit tests. But, of course, you may not have this luxury. And maybe, you’re not writing unit tests, you maybe writing some integration tests – your Setup code may grow bigger. In any event remember – this is not an excuse to stop writing tests. I’d rather pay the maintenance cost, for the confidence and quality the tests give me (although I’d rather have both, if possible).
- Too hard to write the test: See the former. It maybe hard, but Ian’s suggestion to change the production code first, may not be possible. Write the tests, even if it’s hard. Later you’ll be able to refactor with confidence. (And of course, Typemock Isolator‘s a great way to achieve that).
I fully agree with Ian’s closing words: "Test Code is as much a part of a modern software solutions as the production code itself."
You build tests and you will need to maintain them. Think about what you do, how they read now and three months from now. Use them to improve the production code. And treat them as they are – just code.
