Making TDD a habit: problems and implementation

From the translator. On Habré quite a lot of articles on TDD. But unfortunately they do not have detailed information on how to implement TDD in a complex, at the company level. It seemed to me that this article provides an answer to this, and if you set such a goal, then this article may be useful to you.



I ran into teams in our organization that are trying to implement Test Driven Development (TDD). Sometimes one or two developers manage to use it without help, but for most of them this does not work. To better understand the problem, I conducted a survey among team members and found that even after training there is still a lot to be done. This strategy was designed to help anyone implement TDD in an organization, although some of the ideas apply only to medium and large companies.



My research of team members (all of them were trained) showed the following problems:

• People have difficulty using TDD by themselves when they do not have much experience with it.
• In TDD training, simplified examples are used, unlike real systems.
• It takes more time to experiment and try without the usual pressure from management, which requires releasing software regularly.
• There are languages ​​used in the real world, such as Visual Basic and JavaScript, which are never used as examples.
• A typical project is full of legacy code, without explaining how to improve this code.
• And as always there is no time to study - you need to produce a product.

Main problems

Based on these symptoms, what are the main problems?

')

Test driven development is hard to learn. The training phase (the time during which it becomes a deep-rooted habit) usually lasts from two to four months, during which performance decreases. Ultimately, the benefits will be obvious and TDD will be used on its own, but the question is how to make this time appear? Many developers give up after a few days.



Most implementation strategies that I have seen focus on classroom instruction (or e-learning) and one-on-one mentoring. Well done, they certainly reach their goal, but I think it takes much more.



Classroom training suffers from two key problems: the examples are too simple and not associated with real problems, and there is almost no chance to try this in practice.



Interactive learning has an advantage, allowing you to dive deep into the topic. However, there are still not enough chances to try all this in practice. In addition, these courses usually take place without interaction with other students. Hearing questions from your classmates and colleagues, you can often reach an understanding yourself.



Mentoring one-to-one does not scale, except for working with several members of one team at the same time. This is especially difficult in a large corporate environment where there are only a few experts and hundreds or thousands of people who need help.



Books are an excellent option, but few developers like to read books on engineering practices, and even those who study TDD in this way face great challenges. Like online courses, the problem of learning lies on their own shoulders.



And finally: inherited code makes an already difficult task hundreds of times more difficult. Developers rightly ask the question: “How can I test these closely related objects? This code is complicated, how can I test this algorithm? „

One approach

What can work? Previous approaches suffer from two key problems: lack of depth and communication. The complete strategy contains a combination of approaches.

• Classroom Training - Developers need an introduction to TDD, and classroom education is still the best option for most people. The trick is to understand that learning alone will not lead people to TDD.
• Online Training - this will help to consolidate the main ideas. By the way, if there is an optional step in the course of training, then this is it.
• Patience - it will take longer than you planned.
• Metrics - using code coverage tools (eg, Emma , Cobetura , NCover , ...) and explaining to team members that measurement will be just one way to say that things have gone better or worse. Obviously, this does not measure the quality of testing and The result must be taken with a grain of salt.
• Inspire pride - Developers need to know what clean and simple code and tests look like, and they need to feel that it's worth it to tense up. Bob Martin has just written a book called “Clean Code” , which doesn’t give a good account of it.
• Management - Developers need a clear statement from management that they understand that moving to TDD will take time and slow down the team. They need to make it clear that quality is valued compared to the speed and accumulation of technical debt. Most developers are under pressure to produce, produce and produce “useful” code. Managers may have to repeat this statement more than once. The higher the level in the organization from which this statement comes, the more people will listen.
• Pair programming - if you are stuck and do not know where to go next, a partner can often help, even working with another newcomer can be a good start.
• Community - Creating a community in your organization (or city) to share experiences. Place to communicate with other people who learn how to use TDD, learn from one another's successes and mistakes. Place to help grow the culture necessary for TDD. Ability to share new ideas.
• Coding Dojo - A place to practice solving a small problem together. This is a secure collaboration environment with a focus on studying the problem in a group and not necessarily solving it.
• Reading seminars - a group of no more than eight people gather on a regular basis to discuss a chapter from a book.
• Periodic coach visits - can help the team get back on track when they go out of their way and stop practicing TDD. In these cases, a simple pair with one or two people can help re-infect the entire team.

At the heart of this plan lies the creation of permanent communication and the expansion of cooperation around TDD. Three of these strategies focus on this area: pair programming, Coding Dojo, and reading seminars.

Coding dojo

Coding Dojo (using the Randori format) is an event where a small group of people (no more than 15) solves problems using TDD (adapted from Danilo Sato ):

• Work is performed on the same computer with a projector
• Encoding is performed in pairs
• One of the members of the couple switches every 5-10 minutes (everything worked perfectly for us for 7 minutes).
• Developers need to explain what they are doing so that viewers understand what is happening “on the keyboard”.
• Viewers should only comment on the design, in the case when the tests are passed cleanly. When the test is swamped, they should ask questions.
• If the audience is confused, the work stops and developers should explain what is happening.

From experience, I recommend that you choose very small tasks to start.

Reading seminars

There are a number of books for reading seminars:

• for Java projects: Lasse Koskela's Test Driven: TDD and Acceptance TDD for Java Developers ;
• for projects on .NET: Kent Beck's Test Driven Development: By Example ;
• more detail about the patterns of unit-testing Gerard Meszaros xUnit Test Patterns: Refactoring Test Code
• and if your code was not developed with TDD: Michael Fethers Working Effectively with the Legacy Code .

Usually teams process 1-2 chapters per session. The pace is slow enough for people to read outside of work. In addition, it gives enough time for in-depth discussion of several points from this chapter.

Benefits of collaborative learning

Seminars should have pizza (or any other food) - as you ask people to spend their personal time doing something like work, they need an incentive. The two workshops can alternate, so that people do not feel that they are stuck in one thing. And we should not expect that the group will be constant from meeting to meeting.



Seminars and communities are much more useful than self-study, because group members communicate and benefit each other. As a result, we will learn about things that we ourselves would never have reached.

Making TDD a habit

In general, here are the keys that. It seems to me that they help create a successful implementation strategy:

• Patience, practice, depth
• Management Support
• Multilateral approach
• Developers help developers