Test-Driven-Development and Pairing: A Technique to Supercharge Your Development Teams
Ihave recently started a new role at a company that is migrating to a relatively new way of doing software development. I actually have been aware of this way of doing things for some time, but for a lot of people, it is still unfamiliar.
The idea is this: write tests before you write code and work with a pairing partner. Your first reaction might be that this will reduce your capacity for handling tasks, but it addresses two big issues that have really been hindering software development teams: testing and code quality. As much as we desire to have effective testing of our code, waiting to write tests after the code is written often means the tests never actually end up getting written. We also try to pack so much work into a week that often it can be a struggle to just deliver the code even without the tests. When we rush things to try to finish on time, we end up making mistakes, and code quality suffers.
Defects can trickle their way up from DEV through SIT/UAT testing and into production. Defects that are found in a DEV environment are easier to fix than ones found by testers in SIT/UAT, and those defects are easier to fix that ones found in production by actual users. Sometimes this is complicated by having environmental drift — that is, small differences in your environments that can cause the same code not to behave the same way in each environment. This can really slow down the fixing of defects as developers struggle to reproduce and find the source of the defects.
It’s not immediately obvious, but these defects are actually costing your company time and money that is better spent elsewhere. The further away from developers the defects are found, the more expensive they will be to fix (more time will be spent just getting the defects reported, prioritized, scheduled, fixed, tested, and released). Defects found in production are also impacting your customer experience, which has hidden costs as well.
Therefore, it is important to find defects as soon as possible. This is why testing and code quality are so important, and they really need to be a key indicator of how well the development process is working. If you don’t have tools in place monitoring these indicators, chances are you aren’t even aware of how bad things are.
Test-Driven Development (often shorted to TDD) addresses the testing aspect by moving the writing of the tests to the forefront. Not only does this ensure that there actually are tests, it also establishes an important baseline for the developers to know when they have actually finished developing a feature. When you first write the tests, they will all fail, but that is expected since you haven’t actually written the implementation yet.
As you continue to write the implementation, tests start passing. Once all the tests pass, you are usually done (with the caveat that you must have tests for all the requirements of the features you are developing and that you have also considered edge cases and possible failure scenarios). I’m not going to talk about the science of writing tests, code coverage, etc., as that is a huge topic by itself, but even just ensuring that the testing is being done is a huge win for everyone.
The tests also give you some peace of mind in the future as you should be able to validate that new features and changes haven’t broken functionality that you have previously released. It can be incredibly frustrating to your development teams (and your customers) when defects that had been fixed in the past appear again. Fixing defects multiple times makes them even costlier to your bottom line, so a good practice is to write a test for the defect before actually fixing the defect.
As for code quality, this is where the pairing comes in. In our company, we pair program with two roles, the driver and the navigator. Primarily, the driver is the guy at the keyboard who is actually typing in the code editor. The navigator guides the driver, telling the driver which files to edit, where to go in the files, etc.
This isn’t to say that all the coding is done by one person and all the thinking done by another. The two work together as a team, doing all the things that they would do if they were working alone, but with two sets of eyes on the code. With multiple developers thinking and analyzing the code as it is written, the likelihood of a defect being created goes down. I often find that when I have to explain my code to someone else, I think more clearly about design choices, edge cases, and whether some code is actually necessary (as engineers, we sometimes have a tendency to write functionality that wasn’t even requested in the first place).
Sometimes this won’t be enough, and you should be running tools like Sonarqube and Jenkins to automate testing, double check the code quality, and spot things that may not be obvious to even the most proficient developers. These tools can also help enforce simple code quality standards (such as having braces for every if condition, even if the expression in the true case is just one line) that help developers stay out of trouble.
Pairing also has the advantage of helping less experienced developers or new employees learn skills quickly so that they can be more productive. When I join a company, it can take a lot of time for me to get up to speed with the codebase. By putting me in the driver seat and having the navigator guide me, I can actively contribute without even knowing where functionality is located. I don’t even have to really know the full context around what I am writing, as long as I understand the inputs, the expected logic, and the expected outputs.
By using TDD and pairing, you can address some of the most common problems that software teams face, namely lack of testing and low code quality. Writing your tests first ensures that they will make it into the release, and they also serve as a guide to know how the development is going. By adding in pairing, you can improve code quality, reduce defects, and enable mentoring and increased collaboration. I’m really excited about working in this environment, and I would highly recommend it for anyone who is looking to supercharge their development teams.
Originally published on August 1st, 2019.