Your team sees their job as mainly coding, they don’t view testing as their job. They also lack skillsets in how to do testing well.
You’re a big fan of TDD, Clean Code, etc. so you try to convince them to adopt TDD.
📢 My next Live Q&A Session about Unit Tests is on Wed 30th April 17:00. If you’re an Optivem Journal paid member, get your 100% discount ticket.
Upgrade to join the Live Q&A for free:
Jump into TDD without Testing skillset? Disaster.
If you start with TDD, it will be too much cognitive overhead for the team, because TDD requires multiple skills.
Given that TDD is the first word in the TDD in Legacy Code, you probably thought that we’ll be starting with TDD.
If you previously tried TDD Katas, you saw that they jump to TDD straight away.
So, if TDD is better than Test Last, shouldn’t we jump to TDD?
The problems of starting with TDD is that it requires multiple skillsets:
Writing tests
Testable design
Working incrementally
What’s the problem? It’s too much!
The team will get overwhelmed, demotivated, and give up on TDD.
They’ll say that TDD doesn’t work.
We should start with Test Last.
By starting with Test Last, we minimize cognitive overhead for the developers and reduce their resistance. It enables the team to develop the key skillset of writing tests (and being forced into testable design), which is a foundational skillset for TDD.
So later, when they do try TDD, the only *new* skillset will be incrementalism.
The team should gain practice in effective Test Last development before jumping to TDD. The reason is because then they’ll gain experience in how to write tests and, more importantly, they’ll see the pain of writing tests retroactively.
Feeling this pain will be a good motivator to introduce TDD to your team.
Remember, they have to feel the pain of Test Last, in order to have motivation to move towards TDD.
📢 My next Live Q&A Session about Unit Tests is on Wed 30th April 17:00.
Doing TDD (and having never written tests before) is overwhelming!