This is an excerpt from my book Test-Driven Development in Swift. Hope you'll enjoy it.
Convincing a team to adopt Test-Driven Development can be hard.
Breaking old habits and getting used to writing tests for code that is not there yet takes time and effort. Initially, TDD gives you the feeling of moving slower; its productivity benefits become evident only after building a decent part of the software with it.
Some people push back on TDD because they got burned by it in the past. Usually, that’s because they didn’t have the support to learn how to write tests that didn’t get in their way, resulting in a test suite that costs time instead of saving it.”
Moreover, once people get comfortable with the established way of working, changing it will require effort and an initial loss of productivity; being reluctant is a natural defense mechanism.
Don’t force your team into using Test-Driven Development. Instead, teach by example – be the change you want to see in the world.
Use TDD to write your code but don’t make a big deal about it; don’t even mention it to your teammates. People will soon begin to notice two things: your PRs always come with extensive test coverage, and working with code you wrote is straightforward because everything is in isolated and tested components.
Your colleagues will want to catch up with you and start adding tests to their code too. When it’s your turn to review their code, make a point of thanking them for adding tests. Suggests improvements when necessary but always in a kind way; link articles and guides to back up your suggestions.
Eventually, people will start to come to you with questions about testing. That’s the time to talk about Test-Driven Development.
Offer to pair with them to show how you work. Hold a little presentation about how you used TDD to build a useful feature in the project. Suggest it as an experiment and become your team’s “TDD coach.”
If a serendipitous chance to introduce Test-Driven Development doesn’t come up, you can always add it to the agenda of an upcoming team meeting. Do that only after you’ve established a proven track record delivering great code written test-first: you need hard data to convince the skeptics.
The only way to change how a team operates is to have buy-in from each team member. Everyone is keen to adopt something new once the benefits are clear to them. By proactively showing the advantages of TDD through your work, you’ll build a perfect pitch for it.
This was an excerpt from Test-Driven Development in Swift. If you enjoyed it, checkout the to learn more about writing Swift application using TDD, SwiftUI, and Combine.