Once you start unit testing, you will find significant benefits to your design, throughput, quality, and peace of mind. However, it is not easy to start in an organization that’s not used to it. Here are a number of practical tips:

First step: Make sure the motivation is there – as you will see down the list, this change (like most changes) will require the organization to invest time and work in it. Understand the current situation, understand the pains, get some statistics. There will usually be someone who tried writing unit tests – talk with them, try to understand the challenges. Have a kickoff meeting with the team, understand together why are you doing this and how will the process look like. Have a kickoff with management, you will definitely need their support, you need to be on the same page. Whenever it gets tough (it will), get back to this discussion.

Second step: Train the team – I think training should be minimal – just enough so people will understand what they’re going into. Most of the learning is on the job. I do one day training in which I teach the basics of unit tests in the specific technology (I had lately the opportunity of working with an organization in which I taught c# with visual studio tests, react/native with jest + testing library, angularjs with jest and java with junit). We do some TDD with mob programming and finish with unit tests on legacy code techniques.

At this point some people (highly motivated) may start experimenting. Help them.

Third step: Open roads in the legacy code – adding tests to legacy code is difficult at the beginning. Pair with motivated individuals to crack it up, and find patterns to use on their legacy code (see my video about this: English / Hebrew). Sometimes you’ll need utilities, sometimes you’ll need to do some refactoring to allow people to start work.

Are people starting to write tests? Sometimes they do.

Fourth step: Pair with developers – We had the training, we opened up the roads, and now it is time to start moving the ship. Experience tells me I need to sit with almost all developers and pair with them, writing their first tests. Only when you do that realization seeps in. There are many A-Ha moments, I like it.

You would expect people to start writing unit tests by this time. However, change is very difficult. Remember at the beginning writing the unit test is an additional effort. It returns the investment very fast but it is an additional effort.

Fifth step: Let developers write unit tests without you – this is where, together with the team, we start adding the tests gently into the definition of done. They must do it without you, they must wrestle with the legacy code to get it moving. Like other technological challenges, you need some intensity to grasp them. This is the difficult part.

The first time you change code that already has unit tests is a magical moment. The tests tell you the story in simple words, they guide you and keep you safe. The time and sweat were worth it.