In September 2003 I visited the friendly city of Arhus in Denmark to deliver a talk at the famous JAOO conference.
At that time, JAOO was an established software development conference, with well-known speakers such as Martin Fowler, Kent Beck, Linda Rising, and Erich Gamma. And me.
When I arrived at the venue, a conference center on the edge of the city center, one of the organizers offered to give me a guided tour of the building. While we strolled through the center, she enthusiastically pointed out the major rooms where the conference would take place. Then all of a sudden, the organizer stopped at a wooden door in a small hallway. She opened the door respectfully and we looked in.
An ill-lit room with furniture stacked to the walls. “Do you know what happened in this room?” she asked me almost whisperingly. I shook my head. Of course, I had no idea. She continued mysteriously. “This is where during JAOO last year, Kent Beck and Erich Gamma conceptualized unit testing and conceived JUnit.”
Well, you could say that this was my first introduction to unit testing.
The necessity of unit testing
The impact that JUnit had on the industry of software development was tremendous. It was the first viable unit testing framework out there. Consequently, people slowly started to adopt unit testing. Still, it took a long time to gain traction. Even today in 2022, when I ask audiences at keynotes or talks I do at conferences for a show of hands about who writes unit tests, many people still don’t raise their hands. And that’s a shame.
Not too long ago, I was coaching a development team that had come to a complete standstill. They didn’t dare to change another line of code, afraid that their five million lines codebase would break.
Not a single feature had been delivered to their clients in over ten months. When we investigated their codebase, we found a few unit tests, with an almost non-existing level of code coverage, high cyclomatic complexity, and many untested paths in the code. And even in this team, when I stressed the importance of solid unit testing for maintaining quality and speed of development, the developers stared at me with long faces and asked if writing all these tests was really, really necessary.
It is.
Writing proper unit tests takes time
To be totally honest, it took me quite some time to get convinced of the effects and benefits of unit testing and, further down the road, test-driven development.
For authors Kent Beck and Erich Gamma, the number one goal for creating JUnit was “to write a framework within which we have some glimmer of hope that developers will actually write tests.”
They built JUnit with already existing, familiar tools so that there was little new to learn. Plain Java. As they said: “It has to require no more work than absolutely necessary to write a new test.” Gamma and Beck made writing unit tests as simple as possible.
So why is it so hard to start writing unit tests?
From my own experience, despite the simplicity of the tooling, with Jest being my current poison to test my TypeScript and JavaScript code, one problem I think lies in the fact that writing unit tests still require skills and understanding.
It takes time to learn to write proper unit tests.
And time is something we are always short of in software development. There is constant pressure from stakeholders, managers, and product owners to add and improve features in our products. We never seem to have time available to work on the quality of our architecture and our code. Hence, we tend to skip writing unit tests.
‘Not having unit tests is like smoking.’
Another challenge is that the benefits of having good unit tests are reaped in the long run. It only appears to you when you have had a codebase under control for maybe six months to a year. The ease and confidence with which you can change and extend a fully tested codebase is a joy. But only after time…
Read the full article here. An article by Sander Hoogendoorn.
