How to convince a developer to start testing
Let’s take a look at some of the reasons why programmers don’t write automated tests. Of course, this will not be a complete list. I just wanted to point out that most of the excuses are usually associated with a lack of understanding of the essence of automated testing, lack of knowledge of effective testing technologies, poor design of the tested code, etc.
Our experience tells us that this is the only way it seems at the time of writing the code. After some time (say, six months, or maybe even a couple of weeks), the connections of this code with another may not seem so obvious, and the code itself may not be so simple.
Of course, you have to be prudent. After all, tests are not an end in themselves, but a means for shaping the design and checking the performance of the code. You don’t have to test everything thoroughly. Personally, I often do not write tests for non-standard situations, although I write the code that checks these situations. Someone is not at all embarrassed by the increasing amount of code that needs to be reworked in the event of a change in the tested class.
Perhaps it’s all about the level of testing. Unit testing is primarily an activity aimed at shaping the design of a code. If a developer writes code that only configures the parent class or organizes several classes into one, then you need not a unit test, but a functional one. You can feel good about this edge only if you have gained some experience in development and testing.
The developers point out that it is much more difficult to write tests than the code under test itself.
There may be 2 reasons for this:
Low qualification of the developer.
A sign of poor design of the code under test.
We’ll deal with the first point a little later, but for now let’s pay attention to poor design.
At the initial stage of introducing testing into our practice, we had to constantly face a situation when it was almost impossible to write a test for any class. It was necessary to register a user, add a bunch of records to the database, have a dozen configuration files available, etc. Of course, there was little testing experience, but poor system design was the main reason. Because of this, it was difficult to write new tests, they broke very often. There was no need to talk about writing a test before implementation. The reason lay in only one thing – the classes were very dependent on each other, sometimes in a very cunning way. As a result, the system quickly became ossified, resisted changes and gradually became covered with “mold”.
Then we tried to change our tactics and try to test the simplest classes with the minimum number of dependencies. This approach is very well suited, for example, for validation rules, template system components, utility classes. Each test and class-tested was small, and even after a lot of time, it was easy to understand what was being tested and how. The stability of the system was improved.
Gradually, the tests penetrated from the lower levels of the system to the higher ones. We began to have a good understanding of what test isolation is, how to use stubs and mocks correctly, what the trouble is with static methods, what are the roles of classes, etc. Writing tests no longer seemed such a difficult process, and confidence in the code grew. Now we look at code that cannot be isolated during tests in a completely different way.
So, next time, when you abandon tests due to the complexity of their writing, think about whether your project is rotting?
Of course, if you compare the speed of writing a class with and without tests, then it is faster to write code without tests. However, the very process of writing code with tests changes significantly — you only write what is needed for the tests to run. Your classes are getting