Filed under: Culture, New developers, TDD, — Tags: TDD, Unit tests — Thomas Sundberg — 2020-02-27
Some time ago I attended a meeting where a developer told us that
The development is done. Wrote som unit tests yesterday. They are not done. I delegated writing them to a colleague.
A statement like that makes me very sad. It also upsets me.
Sad because it is a missed opportunity to learn more about the problem the developer is working on.
Upset because adding tests seems to be something you do last. You don't understand why, but you do it. It is a chore.
The motivation to delegating the chore was
It is a way for someone to learn about a new system.
Let's look at these statements a bit.
Most people learn by doing. There are very few that can learn a hands-on topic by reading a book. Software development is an example. Reading about unit testing and test first is easy. Doing it takes time. And energy. Test first isn't easy, but it is a great way to understand the problem and come up with a better solution.
In this context, the developers are required to make sure there are a certain code coverage.
There is a quality gate that requires that some % of the code is covered with unit tests.
The unit tests will in most situations be written. But they seem to be written last and
thus miss the goal, making sure that the system is well understood and works properly.
A few synonyms to a chore are
Some of them don't seem to apply in the context of software development, workout is an example.
But what about burden or duty?
In what way is it a burden to spend time thinking about the problem at hand? It is of course a burden if you don't like your job and would like to change. But if you like your job as developer, spending time to think about the problem and understand it better is time well spent. I honestly think that it is your duty to understand the problem properly so you can create a good solution.
When you have spent some time thinking, write a test to document your idea. Then use the test to drive the implementation.
Learning about a new system is often done by writing code in it. But leave a person to add unit tests to something that already is expected to work properly? That's not very nice.
To me, it feels like teaching a bunch of kids to swim. You place them at the edge of a deep pool. You push them into the water. Those that make it out of the pool learned how to swim. Those who didn't make it out of the pool didn't learn to swim.
Teach the new developer about the system using pair programming. And while you do that, write a unit test first. Implement it. Refactor and then write the next test. That would be a safe way to learn about the new system.
If you use unit tests during your development, write them at a point in time when they are fun to write. Adding tests to something you know works is just a boring chore.
Take every opportunity you have to write test-first. It is not easy and it takes time to learn.
If you are introducing a new developer, see it as an opportunity to learn yourself. Pair program with the new developer and write tests first. This will catch silly mistakes later and both of you will learn a lot about the system.
I would like to thank Malin Ekholm, Mika Kytöläinen, and Henrik Jörnvall for feedback.
RSS