TDD: ugh, right?
Like many things in life, when someone expresses a particularly strong positive or negative opinion about something, it’s often because of the influence of specific prior experiences.
I was the same with test-driven development (TDD) and automated testing generally. When I first saw it applied to a front-end heavy application, the experience sucked. The huge suite of end-to-end Selenium tests were forever breaking or producing false negatives, and so took up a huge amount of our time. Time which I felt could have been better spent on manual testing and development work.
But then I joined another team where the test suite was much less of a burden. Developers worked in pairs to produce a small number of end-to-end and a larger number of unit tests before the implementation. The whole test suite was continually monitored and improved by our test lead, striking a balance between risk and overhead.
So when I talk to developers who are vehemently against automated testing and TDD, I make sure to ask them why and dig into their previous experiences. I don’t think that TDD is the One True Way and that you’re less of a software developer if you don’t work that way. But I do think that it needs to be given a fair chance.
In the past, front end development has often been lambasted for its lax approach to testing and TDD, and indeed for its lack of rigour generally. That was really down to three related challenges:
- Lack of experience of testing skills and experience among front end developers.
- Lack of educational materials and established patterns for applying TDD to front end code.
- Lack of or poor quality test tooling: test runners, libraries, frameworks, IDE support and debugging tools.
All three of these have improved in recent years, but for me there is still a lack of emphasis on testing and TDD as core expertise. Often the focus is on tools (again!) rather than techniques and approaches.
Given the impact that the test-driven approach can have on software design, this is a problem. Many people struggle with TDD because they lack the overall conceptual framework that helps them progress through an implementation.
Almost immediately, TDD throws up more questions than it answers, and there isn’t enough guidance out there to help with that.
TDD requires a gradual unlearning of well-established thought patterns as much as it does a learning of new ones. This is hard to do by yourself. I was interested in TDD for a while, but only really started learning about it when pairing with someone with lots of experience. I needed someone sat next to me to bring me through that initial hump of resistance and doubt.
It was only after a few weeks of this that I started to feel positively towards TDD as a practice, and started to see the benefits in the code I had written. The light bulb moment for me was when I had to go back and modify some code that I’d written in this style. Now I just feel uneasy if I don’t write tests first.
What’s your view of TDD? How has it been shaped by your experiences of it up to now?
All the best,
– Jim
