As a technical leader you often face issues such as slipping deadlines, a growing backlog of bug tickets, and teams constantly requesting to pay down technical debt. Any of these issues could bring your organization to a screeching halt.
Even industry practices like mandating coding standards, PR reviews, and frequent architectural board meetings don’t seem to quell the ever rising tide of quality issues on software teams.
Automated tests may be the missing piece in your technical tool chest. Specifically, those automated tests written using test-driven development (TDD).
What are the benefits of TDD?
The benefits of TDD appear once engineers begin using the three-step flow of red, green, and refactor. Each phase reinforces critical thinking about the quality of the system. Since the benefits are tied to the thinking that each step fosters, I need to briefly describe the process.
Red is the phase when engineers specify the program requirements by writing a failing test. Green is when the minimum code is written to make that test pass. Lastly, refactor allows for improving the design of the code that has been written. With an understanding of the overall flow, I can now tell you about the benefits of each stage of TDD.
Red. When engineers have to specify what the program is supposed to do before implementing it, they have to think. It is not possible to implement a new feature without having an understanding of what the inputs are and what the outputs will be. Thinking about the system naturally leads engineers to wonder how a program should handle unexpected inputs. Those edge cases can then be flagged to the product team and addressed correctly, before the feature ships with bugs.
Green. Engineers make the failing tests pass by implementing just enough code. This step directs programmers to wonder, “What is the minimum solution to the problem I am trying to solve?” This question leads them to actively reduce the complexity of the systems they write. A simpler system with fewer unnecessary elements will result in code that is easier to maintain. Tests also have the benefit of being a type of documentation that can run, to verify that it is still accurate.
Refactor. The final phase of the TDD workflow invites engineers to take a few minutes to improve the quality of this newly written code. This improvement isn’t like the complete rewrite that is typically requested. The goal is not to pursue poetic beauty but to make the code express its behavior clearly. This clear expression can massively reduce the risks commonly associated with transferring code ownership, as this code is easier to read, requiring less documentation.
Since the team is thinking deeply about the system, seeking clarification on edge cases, and continually redesigning it in small chunks, progress will begin to happen more consistently. This means that you can focus on product initiatives instead of technical quality.
How to start writing tests
Odds are that there is already someone in your organization who is passionate about writing tests. One tactic is to find that person and give them the support they need to start mentoring others to write tests. Something like giving your local expert time to pair-program with other teams can really pay dividends without much investment.
Another way to amplify that person’s influence is to have an experienced public speaker in your organization help them craft a workshop. This workshop could then be given at some cadence with optional attendance from any team. The point is to let the idea be publicized and evaluated by teams based on its usefulness. If you avoid mandating the practice, it can spread faster. TDD is like any tool; if it is helpful, people will use it.
If there is no one in your organization already practiced at writing tests, then creating incentives to allow people to learn TDD may be valuable. Try using a few of the resources mentioned below to run a book club.
The book club could meet biweekly and be a space for developers to learn together, reinforcing team and organizational bonds while simultaneously promoting testing.
Still another way to promote testing would be to pay for interested folks to attend TDD training courses. This idea shows that your company values them and their work, and it creates an opportunity for them to improve.
Some great resources for learning more about TDD
Here are a few resources that I found very helpful when I was first teaching myself TDD.
- Test-Driven Development by Example. A short book written by the man who popularized the practice of TDD, Kent Beck. The book demonstrates the step-by-step thinking about functionality and quality necessary to do test-driven coding well. It teaches readers the core principles of the red, green, and refactor workflow, and then it shows a few more complicated use cases: writing a money class, implementing a test runner from scratch, and finally a few common testing patterns. Taking the time to write out the code examples in this book is one of the best tutorials around.
- Object-Oriented Programming Guided by Tests. Another very popular book in the TDD community that shows developers how to test-drive an auction application. This content, written by Nat Pryce and Steve Freeman, will introduce your engineers to end-to-end testing, the trade-offs between mockist and statist testing styles, evolutionary architecture, and a few other gems—I will let you discover them for yourself. This in-depth Java guide is a great read, even if your teams are practicing functional programming, or not using Java.
- The Magic Tricks of Testing, by Sandi Metz. Although this talk uses examples in Ruby, it contains a wealth of knowledge on how to create more testable designs for your code. Sandi goes in-depth on common message patterns that systems use, and whether to choose mocks or stubs, and she also gives some sage advice on when breaking the rules can be helpful.
How Stride can help your organization with test automation
After exploring these resources, if you need further guidance on improving your testing practices, then Stride is fully prepared to help. Our engineers will collaborate with your developers to deliver software while showing them how to use TDD—what we call “player coaching.”
At Stride we also value building products. We regularly demonstrate the value of TDD by showing how it can help ship software in one of our delivery engagements.
If you are interested in collaborating with us on making test automation a core practice in your organization, we would love to hear from you.
Steven Solomon
