In the TDD / XP circles I hang around in, sometimes the question comes up of why isn’t TDD more popular? If the practice helps us write better software at lower cost, surely everyone should be doing it?
So why are these ideas not mainstream?
I think the answer is partly to do with our own bias but also because we are terrible salespeople.
I’ve met untold numbers of people who believe that TDD practitioners are a bunch of grumpy perfectionists who will judge everyone else’s code, try to rewrite everything in their own style, and bring a reign of terror to their team.
No wonder people don’t buy into it!
So how can you be a better salesperson?
You MUST learn to enjoy bad code
I’m a contractor, and I specialise in TDD and XP practices. Since I started contracting, I’ve heard the following twice from two different clients:
“Oh, you won’t like it here. We don’t do TDD. We have some test coverage, but we’ve also got an overly complicated design and a lot of tech debt. I doubt you’ll enjoy it. You won’t be happy here.”
At the time my response was pretty clear:
If I was only happy when I’m working in a well-factored and well-tested codebase, I’d never be happy. Those codebases aren’t just rare, they don’t exist. All code is terrible.
So the first lesson for anyone who enjoys TDD is make peace with the fact that you won’t get to write software your way all the time, and not even most of the time.
Try not to judge other people’s code when you read it
I have to try really hard to not judge other’s people code when I’m reading it. It takes a lot of skill. I think we all probably do it. You’ve got your ego to thank for that.
Since reading other’s people code is an integral part of any professional developer’s job, it’s important to not get too emotionally involved in the task. Otherwise you’ll be frustrated a lot of the time.
Of course you still take pride in your own code. But you should also take pride in your team’s code.
Notice how other people judge you
I’ve thought a lot about these client interactions. On both occasions I remember thinking, why do you have a low opinion of your own software? You should be confident and proud of our creative output, however messy the codebase. Your business is clearly successful. And you probably have the software to thank for that.
But I can see another side to it: this is what they have learned to expect from a TDD / XP consultant.
They read my experience and credentials, and judge me or put me in a box based on their own prior experience with people like me.
That’s a perfectly normal thing to do, and I’m just sorry they had such bad experiences with TDD practitioners in the past.
Stealth testing: don’t tell them about it. Wait for them to ask
Win trust by consistently delivering high-quality software. What I mean is, over a period of many sprints, deliver what you estimated you would, and deliver it bug-free.
You don’t need to focus on how you’re doing it. Just do it and eventually people will start to ask you how you’re doing it. That’s when you tell them.
Teach them by going very, very slowly
Once they’re interested, it’s over to you to show them why your techniques are awesome. Pairing is a great way to do this, but make sure you slow down. If you try to build features at the rate you normally do, you’ll lose them. They have to be able to go at their pace and feel supported.
Perhaps one day, all developers will write tests...
Top comments (15)
Sometimes is maybe because testing got appropriated by TDD, if you don't do TDD you're not testing, if you don't TDD you are worthless.
I don't like to write the test before the code, sometimes the whole structure of what I'm coding changes when I'm writing it so to make the same test over and over is awkward to me: maybe something in the current function started to look a lot like some other function I made and now I wasted time testing something twice or writing the code I realize it got some new condition to test that may invalidate the previously made test.
To me is annoying and I see no benefit from it, said that, to me, untested code is as unfinished as not running code, just because it compiles doesn't mean it does what it supposed to, so is not yet working code. Not even in my local repo I ever commit something not tested. Not tested is just a mockup and you don't mix mockup code with working and commited code.
Sadly TDD took over testing so people not liking TDD end up ditching and avoiding testing, why bother, if is not TDD is garbage anyway. It became a credo, something to blindly follow without question, and to attack anyone that don't follow the holy path. Almost like Agile, OOP or Robert Martin. Sacred words.
I did TDD once - properly. When I was building a cube library. It was a way to translate queries into MDX statements. I tried designing the application, like normal, and kept getting into knots. So I wrote it using TDD, and surprisingly with a bit of refactoring - the library was aweseome.
That was seven years ago and not for a client.
I only really write tests when working through logic or ideas. Very occasionally, if there are calculations or something which was hard to do and would benefit from a test for a developer in the future to view.
It is a strategic/team decision as to whether to have unit tests to help reduce regression fixes and completely agree it isn't something to undertake blindly.
Offtopic
It sounds like an euphemism, sorry I had to say it, I couldn't help it. :D
Could probably think of funnier euphemisms, but it works. :)
you probably could, but that one, is special, it wasn't planned, came directly from your heart. :]
and that is usually boring. :)
I like the idea ”not tested is just a mockup.” Similar to Michael Feathers’ definition of “legacy code.”
Testing is a whole bag of tricks and just the mention of TDD can turn someone away from testing entirely, which is unfortunate.
TDD is just a methodology, one of many, suited for some cases and not so much to others; some people feel comfortable with it and write better code because of it, others feel it awkward and cumbersome. TDD is not "the best". There are no recipe to write good code, just some guidelines and advices.
I think some aspects of TDD get too "personal", you can tell your employees what structure the code should have, deadlines, even format and style, but things like when to write the test, the order you make things, to me is too invasive, you are messing with the internal process of the programmer. Who cares if (s)he writes the test first or after, demand a proper test, trying to control the process is micromanaging and nobody appreciate that.
Hi Daniel. Gave you a heart, as it is probably a lonely existence being the judge,jury and executioner.
I think the honest reason why most development teams don't do unit testing, is because it is a big undertaking. Especially in enterprises. Code is simply additions to a platform, and testers, and users will pick up bugs during the SDLC. This sounds lazy - but my roles tends to be more data focused, and when working in development environments (not production...) or greenfield there isn't the data to assert the units.
As terrible as it sounds - you may not know if your applications behaves correctly until it is in Integration. Project teams have two decisions - create their own datasets for testing OR put it in integration and test in there.
I took a look at your sites and will bookmark this. Cheers.
Unit testing doesnt take the place of integration and e2e testing. Used together they become whole and eliminate the need for testers. It is the developers responsibility to check for failures through different tests in my company.
If you skip on unit tests, tests will run slower and be more brittle for the same test coverage
I like using TDD to organize my thought, build my business logic while evaluating the success of my code. It's more of a methodology.
I tried using it the first time when I was working on a project with a ton of technical debts (btw, I don't judge a codebase, if it doesn't create a big amount of problems, but if I must work 5 days instead of 1 on a bug because of the terrible written code, then sorry but yes I will have something to say about it) but I use TDD only when I feel it is necessary not just with the test coverage in mind. It's more of a way to clear my mind.
I have never done TDD, but I like to definitely write tests for all my business logic. I think with tests you can become confident, that you have covered at least those scenarios which you can think of.
But I think instead of developers becoming convinced to write tests, I think it's management who have to be convinced why we need tests, and how they add to overall project quality.
Thanks for this comment. I agree that people have different motivations and that TDD appeals to only a small proportion of people. Plus, there's often no incentive for devs to test--their performance isn’t linked to it, especially when companies have specialised test teams. Which all tallies with what you’re saying. What I disagree with is that testing can’t save time/money—while that’s certainly true for a lot of people, for many contractors/consultants testing becomes the reason why they are so highly valued in the community, because they can build maintainable, high-quality software that is built to last.
However I think the problem lies with the TDD/testing community on this one. We need to innovate. To find ways that everyone can be successful with testing and incentivize it enough that all devs want to do it, not just the ones that enjoy writing testable code.
Being able to take a TDD approach usually requires an idea of how to build testable code. Hell in some cases one might not have any idea what the code looks like at all, so testing it isn't possible.
At that point it just seems like an afterthought, and untestable code is one of the easiest ways to get some cheap tech debt.
Now getting around that sort of barrier is pretty hard since it requires more experience and discipline.
I use TDD for business logic, but convincing others to do it is difficult. I also find that continuing to do it as an example to coworkers is a good strategy.