Which small bicycle with chrome-plated handlebars..

TL;DR: TDD is like biking:

– it's faster than walking

– it's counterintuitive at first

– once you know how, you never forget

- I heard that you're working on the new XXL project. Congratulations! How is it going? - Not bad. We're facing a few difficulties setting everything up, but nothing too bad. - what kind of difficulties? - Well you know, integration with new frameworks, a few bugs and quirks here and there... - Bugs? do you have tests? - The Product Owner does the tests for now... - No I meant unit tests, automated tests, written by developers, against their code. You know, like I showed you on the XL project. - Oh! Unit tests, OK! Yeah I told the team about it, but they don't really have the time right now, we have to ship stuff. - Oh dear, stop. - What? - They said: "We don't have the time to write unit tests because we have to ship". - Yes. - Is this a joke? - I swear it's not. What are you thinking? - Your team doesn't know the kind of tests that I'm talking about. If it were the case, they would write their tests right now instead of putting them off. For now, it seems to me that they fell into the beginner developer's trap. - The beginner developer's trap? what's that? - "We will improve quality later when we have the time" - How is it a trap? - It will never happen. - How do you know? - Today, you have some quality issues. - Yes, only a few, nothing overwhelming. - Was it in your roadmap? - Not really. - Therefore, you already have more work needed than planned. - Well, that's the reason behind putting off automated testing, you see... - Because later, you'll have less work to do? - Maybe... - Just to be sure: Tomorrow you're going to tell your Product Owner "Indeed we spent some unplanned time fixing bugs, we are a bit off schedule, but we made a release. Now, what we would like to do is to deliver a bit less features and take the time to improve the quality of our codebase". - Well I wouldn't put it like that... - There are not a thousand ways to put it, in my opinion. - Alright, OK. But today, the team needs to show some results. - Of course. It's essential. And they also need to learn. - What do you mean? - Your team says: "We'll do the unit tests later because now we need to deliver features." I infer that the developers in your team don't know unit tests and thus need to learn. - And why unit tests? Why not rely on acceptance tests at the end of the sprint? - You can see that this is not enough. You already have several bugs. - Well, we'll ask the product owner to do more testing. - Don't do that, it's a waste of time and effort. - How is it a waste of time? - Acceptance tests will become harder and will uncover less bugs than you would with unit tests - How are you so certain? - First, your product owner can validate the product you are making but cannot validate your code for you. - Granted... - Second, even if your product owner validated your code at the end of each sprint, it would be too heavy a load of information to be efficient. Do you honestly think you can fix a week's worth of code each friday afternoon? - Don't tell me about it, we already have a hard time merging versions from two workstations... - Third, even if it were an acceptable feedback delay, once the bugs are uncovered and fixed, you would certainly look for a way to avoid the same kind of bugs in the future. - Obviously! - To detect bugs in the code efficiently, you need a systematic approach: write unit tests as close as possible to the code you are writing. - What is the closest as possible? - The sooner, the better: at the same time you are writing the code and in the development environment. Remember what I showed you on the XL project - You mean Test Driven Development? - TDD or any other technique which allows to write tests close to the code. - I should talk about it with my team. - I wouldn't wait too long if I were you. The developers in your team have everything they need to write code of good quality: JUnit and a working brain. - Yeah, but you know how it is, tests are considered like a chore - That's the first thing that needs to change. It's because your team is not trained. - Hmm. - Do you remember the time when you were learning how to bike? I remember. I had a brand and shiny new one! Because I didn't know how to ride it, I use to walk alongside holding and wheeling it. It was fun at first but it quickly became frustrating, even for others, because they had to wait for me. My sister then explain to me that the "thing" with bikes is to hop on it and ride. It goes a whole lot faster. The bike carries you, not the other way around. - What happened next? - I crashed quite badly, obviously. It didn't work out. My sister, who must have been tired of hearing me whining, climbed down from her bike. She explained how it worked and she helped me by holding the saddle while walking beside me. When she had to run, I knew how to ride, simple as that. - What's the connection with TDD? - TDD is like riding a bike: it makes you go faster provided you invest a little time to learn how. Your approach to testing "later, maybe, if we have time" actually slows you down. It's exactly like walking along your bike. - What do you recommend? - Give it a try! You need 3 days to learn, 3 weeks to make it a habit and in a few months you'll completely master the approach. - Ok but right now, we don't have much time... - You're doing it again... - Just joking! Thanks for the advice. I'll talk to the team!