TDD Is A BROKEN Practice

🎓 FREE TDD TUTORIAL: Explore what it takes to get started, and how to learn these skills, with a hands-on demonstration of TDD. Study alongside me FOR FREE HERE ➡ courses.cd.training/courses/tdd-tutorial

I don't know the complete context, so I'll add a comment based on my experience. People often confuse TDD with unit test, and unit test with class/method test. When they do this, they get stuck with fragile tests, that need to be rewritten as soon as something is changed. In my experience this is why people see TDD as something that slow them down.

If people put as much effort into practicing TDD as they did into coming up with elaborate excuses about why it doesn't work for them, maybe there'd be less lousy code in the world.

The only way to have full confidence that you haven't broken anything is to test (almost) everything. I've been on teams where there has been a "no unit test" cutlure and it sucks. Everyone is scared of breaking production.

TDD is unpopular because it is a skill and people don't recognize it as such. They try it, having heard the slogan "test first" thinking that's all there is to it, fail, and give up on it. TDD takes practice, and the result is well worth the effort.

TDD is something I liked really early after getting introduced to it. I was convinced after the first try. I have foresight of what I want to implement or I have to go back clarifying requirements. That does not mean that I have to know the final state of the finished product. It works really fine for developping prototypes. As an added bonus I do not have to think about getting the parameters into the next increment. The code quality is good not because I am more of a genius than other developpers (which I probably ain´t). It´s good because the tests encourage good design and catch errors before someone else had a chance to spot them. Also it makes handing projects over a piece of cake. Want to know how it works and how it is suposed to be used? Just look at the tests.

I have recently became a firm believer of TDD in my work environment. As a developer, it forces me to have a good understanding of the requirements that needs to be done and plan ahead of what the logic ought to be, it is especially crucial in complex services. TDD has minimised the carelessness in my codes, in terms of data models being sent and also the logic itself. It also helps to decouple your codes trying to make it testable, and when the section of code is decoupled, it’s easily scalable as well. Yes, it takes quite a while to setup the testing environment and time consuming to write test cases (I still hate it, but it’s necessary) but at least when an error/bug pops up on your end, you would have a clearer picture on which part of the code the error/bug occurs. It actually saves so much maintenance time in a long run

I loved that comment that test driven development has test in the name. I think that expsoes such a weakness in our profession. That is that we think we don't need testing because we get it right. Yet we can't. Getting software right the first time is only possible for the most trivial of cases. Getting the design right even harder again. I drink from the fountain of TDD and try my best to get better at it. However i have not worked with many people that feel the same. Testing cones last of at all. Tests for commented out when thr pipeline fails to increase velocity. Oh well.

The one thing people forget about TDD when they say that they don't know what the system should do is that this is a lie. It is a lie simply because they have the requirements of the system that put boundaries of what the system can do. You use TDD to anylize these boundaries, to design around it and to develop the code that delivers the required behavior.

The basic problem I have with TDD is that it's just not how the creative process works for me. If I'm trying to figure out a hard problem at work, I might be relaxing doing other things on a Saturday when suddenly an idea pops in to my head. My reaction to that is to go to the computer and start implementing that idea. It's not to go to the computer and start writing tests for a solution to my idea. To me it would be like having an idea for a piece of music and instead of sitting down and immediately trying to play that music, try to figure out who you should call to listen to the yet unfinished music when it's done. To the people who do TDD: If you get an idea for a play project outside work, and you're all exited about it, do you immediately run to the computer and start writing tests? The first time you heard about Sudoku puzzles, and you figured that this problem should be pretty easily solvable by a computer program, did you sit down and write tests before you wrote the 20 lines of code that solves Sudoku? I just wrote the Sudoku solver. And if I were to write it as production code, I would subsequently have written some tests.

TDD is wildly unpopular because most people don't think backwards enough to naturally generate a flow starting with tests.

Excellent info. Well explained. Thanks.

Great video! Your point that developers who initially try TDD imagine the code they would write, then make a test according to that imaginary code, is bang on. It wasn't till i grokked that i needed to let go of that mental code, and write a minimal test to start with, that i began to truly get how TDD works. I saw a live demo of TDD from Bob Martin that really helped my understanding of it.

I often end up going back and forth between the code for a function and the test for it. I work with a lot of numerical libraries and sometimes I am not sure of what the output for something is that I need. For example what is the shape of an array that will result from a function call and how is the data in it arranged. I often find myself making a tiny function and a minimal test just so I can see the code do something and I can verify if it is called correctly. I then tend to flesh out the test a bit to cover what I think the function should accomplish. I then go to implement that in the function. Sometimes I find that the way I wrote the test has results in a very poor design in the function and that with a few changes to the test I can make the function cleaner. Sometimes I find out I need to split out some parts of the function into multiple functions. I find that tests really help with the design process.

Personally I think TDD is taught in particularly stupid ways. The way it is taught often implies that even the most stupidly obvious parts of your function are going to be iteratively constructed only by adding a test for them first. That makes no sense in practice. Of course if you are going to write a function to add up two numbers you are not going to write a test first for a function with zero parameters and a function that takes zero parameters, then a test for a function with one parameter and change the function to take one parameter, then another test for two parameters, then a change the function to take two parameters,...

I don't believe every tool works for every project, but I did have the joy of working on two projects that were TDD. And when management realized they missed something on Thursday afternoon, we could implement it and the new tests Friday morning, run the tests for a few hours, and deploy to production at 4pm on Friday and go home without a care in the world. We never had an interrupted weekend.

For the tricky aspect of 'getting started', one should reflect on the RGB cycle at 6:08 and ask where do you start, what do you start with and why. While the process is (appears to be) a continuous cycle, you need to ask how to start and how to end the process (just like the difficulties of starting and stopping major chemical plants - explosions everywhere, unless..). Getting started with TDD still needs a start-up phase. One should 'start' at refactor for your non existent code and the vague concept behind it. This is refactored into a more concrete concept and some pseudo-code, which can immediately be supplemented by its (hopefully) passing test concept. This is then quickly followed by converting the test concept to pseudo-code, to code, and back to refactoring the real pseudo code to its own code which now has a test that reflects the concept under test. And it probably 'fails' (the pair doesn't do what was expected). It may even be necessary to mentally split your existing coding approach to split out a small portion that is essentially just there to help visualise how it's working - call that your 'tests'. It's important to realise this is really as shift of mental model from the appearance of a code-code-code approach to code-check-code-'code the test' approach.

Point about UML/SysML - we can practice so called AMDD - Agile Modelling Driven Development - which is basically TDD + diagram/sketching before those tests for those small units.

Interesting video, definitely some good for thought. I've never practised TDD but I have, of course, mentally thought of the objections you mentioned. Your counterpoints are pretty good tho so I might try and put some effort into trying some TDD with my current personal project.

Fully agree with your analysis of the failure of UML-driven design. However, I do believe in Model Driven Design where the model is a Domain Specific Language.