When there are no tests at all in your project (Let’s Smell Some Tests #0)
Why it’s worth to write unit/integration tests, and how I managed to convince the team to start implementing them
Hello and welcome to a pilot article on smells surrounding unit tests and integration tests.
For me, as a programmer, implementing automated tests is an inherent part of the software development process. Writing tests is not an easy task, generally speaking. And writing good tests is even more difficult. But we are developers, and developers do like challenges, don’t we?
So, how to distinguish good tests from bad ones? How to refactor bad tests so that they shine again?
I’m going to answer these questions, but as this is a fairly large topic, all the issues that I would like to cover are not suitable for a single article. Because of this, I decided to create a more digestible form and release a series of articles devoted to this topic.
Let’s get started!
Tests are sometimes underrated heroes
Writing tests perhaps is not the most impressive entry on your CV, and you might prefer to work on some real challenges that bring some business value. Why do we focus on testing then? Here is the thing: automated tests bring value, too. It’s because they protect our functionalities and alert us whenever something works differently than we expected. For the business and end-users, these little guardians are invisible, but thanks to them we can mitigate the risk of bugs released into the production environment. I think this argument is convincing enough to start writing tests at all.
But just writing tests is not enough, however. As it happens in real life, nothing is for free and automated tests also have a price tag. There are several factors that contribute to the final price, for instance:
- time and effort to implement tests
- maintainability of our tests
The first factor is rather obvious. When we estimate a user story during the planning session, and we know that we want to deliver the functionality covered with tests, the task will be more time-consuming.
The second factor, maintainability, can be less obvious. If we just spread the assertion statements in the code without any plan, there is a high likelihood that we’ll end up with a severe headache at some point. Eventually, we will come back to these tests and rewrite them, otherwise, they will be like a recurring migraine.
Tests? What tests?
Before we move on any further, take a look at the title of the article again. This article has the index “0” in the title not without a coincidence. The first smell that should alert us is the lack of unit/integration tests in the codebase.
Zero. Null. Or a bundle of prehistoric tests that weren’t touched for ages.
My real case
In my programming career, I happened to join a project where writing tests was almost completely forgotten. I am writing “almost” because there were some legacy tests out there, which were written by developers that no longer worked on this project.
What’s interesting, the test execution phase was neither included in the build process, nor those tests were executed on a continuous integration server.
By comparison, in the previous project I was working on, the developers regularly wrote integration tests, so there was a safety net that caused less stress when making changes to the code. In the new project, however, the codebase shouted out clearly that it was never meant to be tested out by unit/integration tests.
The situation in which I found myself was something new for me and subconsciously I felt that something was wrong. When I asked the team what is the reason the existing tests are turned off and the team doesn’t implement new ones, I got the following responses:
I am not fluent in writing tests
I don’t write tests because it costs too much time
I can implement my task in one day, but writing tests covering this functionality will take another two days
It’s hard to write integration tests
It takes 15 minutes to execute the whole test suite, so we don’t write tests
After I got these answers, I decided not to judge anyone or urge anyone to write tests (especially since I just joined the team and didn’t want to be cocky).
What I’ve done instead? I started writing tests for user stories I was taking and was pushing these tests along with the main code. I did know my tests were not going to execute automatically, but I still was able to launch them manually if needed. Plus, I was hoping that pushing my code with tests for code review may interest other team members.
How did it end up?
It turned out my hunch was right, and the team gradually became interested in tests that I wrote for myself ;).
This motivated me even further, so while participating in the aforementioned project, I set myself a few goals focused on testing:
- convince other developers to start writing tests when they develop a new functionality
- enable automatic test execution for every build in CI tool
- shorten the total test execution time
It seems that I can modestly say that I have had little success in this matter and can tick off all the above points (in terms of total test execution time, I shortened the time from 15 minutes to about 3 minutes).
Be humble
In closing, I would like to share some thoughts on the subject of interacting with people.
Admittedly, programmers spend a significant amount of their time talking to computers. At the same time, we should not forget that we often collaborate with other, live team members.
When I recall the arguments why the team from the story above used to not write tests before, I think we should not judge prematurely. If someone is doing something in a way we think it could’ve been done better, just stop for a second and think about it this way:
maybe this guy does his best and puts much effort into his work
What I mean is even if you are deeply convinced of your knowledge and you’d like to enlighten someone, try to understand the other person’s point of view. Nobody knows everything, so don’t be cocky, because there is a high chance that there is someone much smarter than us :).
Moreover, if your teammates openly admit that they are not proficient at something that’s a very good sign. I value honesty in people, and it’s not a shame to admit that we something simply doesn’t know. Use your knowledge then and teach these people just as you wish you were taught.
Also, if someone tells you they are not doing something because they are not fluent at it, then try to explain that only practice makes perfect and that the only way to get better at it is to do it. The hard truth is that being passive won’t help them get fluent. The good thing is, however, at some point they will realize the activity is more natural to them, and then they can proceed to learn even more difficult stuff.
What’s next?
In the next article, we’re going to take a closer look at one specific test smell, which we will analyze, find its origin and provide an alternative solution to keep our code nice and clean.
