Testing is NOT expensive!
Writing unit tests can actually lead to writing fewer lines of code.
A few weeks ago I was at an introductory talk at my new job as a junior software developer and one of the more senior developers got to talking about testing code. As he was speaking, I remember him ending a section of his talk with the words, “testing code is expensive.” I was reluctant to raise my hand and start a whole debate about how my experiences with a Test-Driven Development (TDD) approach to writing code have actually led to me writing fewer lines of code so I thought I’d write this article to share my opinion.
“testing code can be expensive, but doesn’t need to be.”
I disagree with the statement, “testing code is expensive.” I believe that testing code can be expensive, but doesn’t need to be.
I was introduced to this concept of unit testing and TDD in my third year at university and I must admit, I hated it! Having to write extra lines of code just to prove that which I already knew to be true was infuriating and time-consuming. Writing the tests took just as long as writing the actual source code, if not longer. So if I had listened to that talk back in 2017 I would’ve agreed wholeheartedly with the opinion that testing software is expensive, because it was! My views about testing code changed dramatically when I stumbled across a book by Eric Elliot where he used TDD not just as a tool to test his code, but as a tool to write less code.
“we all use TDD when we write code. It’s just that most of us do it unconsciously and never keep any of the test code.”
Believe it or not, we all use TDD when we write code. It’s just that most of us do it unconsciously and never keep any of the test code. You see when coming to the conclusion that writing tests results in time and effort being wasted, we forget to count the many lines of written and deleted code in the console logs. The many “cout”s and the “printf”s… I call them the forgotten test scripts. It has been my experience that these forgotten test scripts can be much longer and more time consuming than the formal test scripts that we write.
Writing formal test scripts helps developers follow the famous Do Not Repeat Yourself (DRY) principle by preventing the constant cycle of writing and deleting and commenting out and rewriting test code. We should all write unit tests as a way to keep our tests documented, logical and reusable. It’s only when people start to obsess over things like 100% code coverage and large end-to-end integration tests that we begin to lose the plot and start making the writing of tests expensive.
TDD can and should be used to make our lives as developers easier.
I could go on and on about this for pages but I fear this article will be too long if I do so I’ll just end it with is; TDD can and should be used to make our lives as developers easier. Writing test code should be used as a way to document and reuse test code and to avoid falling into the trap of writing those long, time-consuming and repeated yet forgotten test scripts.