I'm curious what the dev.to community's experience is with TDD. Any success stories or horror stories?
For further actions, you may consider blocking this person and/or reporting abuse
Read next
Top 24 Integration Testing Tools You Should Know About in 2024
Jennifer Smith -
How to run Selenium tests on Chrome using ChromeDriver?
Steve Wortham -
Join the Open-Source Revolution with AxioDB: Calling All Developers!
Ankan Saha -
We made a horror movie inspired by spooky prod bugs 🎃
Ivanha Paz -
Top comments (9)
I've had regression horror stories from not having tests, but not so many from having them in place. The harder part of TDD for me is the initial config.
I think the worst TDD story I've encountered was on a legacy project for a client that decided to start implementing code coverage. If we worked on a new feature (or bugfix) that used a function written years ago without unit tests, we couldn't deploy the new feature (or bugfix) until we wrote unit tests for that old code, even if that old code wasn't directly relevant to what we were trying to do. Made scoping and estimating hours a bit of a nightmare, but on the plus side we always shipped good code!
Oh yeah, I can completely see that. It is so hard to retrofit unit tests into code not written with testability in mind.
I don't know if you are familiar with the book Working Effectively with Legacy Code but one of the recommendations they layout is to a high level / black-box approach when it comes to testing legacy code.
How did that project turn out, did they persevere until they had high code coverage?
The project has turned out well so far, and they are still persevering! We're continuing to get work from them in 'buckets of hours' contracts, augmenting their in-house team, though I think it will be a while before they achieve their desired level of code coverage.
I love that idea of treating legacy code as a black box, and will definitely need to read that book. Since the project may have left a sour taste in the mouths of coworkers whose first exposure to unit tests was on this project (and experienced the nuisance of failing pipelines due to missing tests), that black box approach might bring them back around. Thanks for the recommendation!
When I started doing TDD, I wrote a quite complex backend server for machine to machine communication in a small start up alone. I did it completely TDD. By the time I was finished coding, I started it and since then it ran, no bugs in production.
That sounds very validating. How did you test the integrations to other machines?
Good question. This project was almost 10 years ago, I have to say can’t recall all the details. But we’ve already had a well defined model for the communication.
However, now I remember one thing that actually didn’t work - because I couldn’t test it. It was the database queries. There had been bugs in the queries itself.
Nowadays, I would simply write integration tests with SpringBoot and test containers to validate the queries.
I'm having to really think hard about horror stories with TDD. I've seen lots of horrible things with terrible automation and mocking, but rarely does that and TDD wind up together.
I've been doing TDD as one of my primary development techniques for about 7 years now. I can honestly say that TDD has resulted in the most profound improvement in my coding abilities compared to anything else I've done.
My current team that I'm consulting has adopted TDD over the past few months and they've eliminated all their bugs in development and production
Yeah, I am in a similar spot where I have been doing TDD for about 6 years now. TDD the general grab bag of tricks from XP style development has completely changed how I develop code and work with a team.
I've not had any horror stories per se. But for me it really depends a lot in which context one tries to do TDD, how successful it turn out. For me it's relatively easy in the business layer when you have clear specifications of how a feature should work. I think it's harder, in an Angular client if you for example do a proof of concept to have something to reason about with the client.
But. It is in those cases, where the specifications is not that clear, is where TDD in a way shines. Because it forces you to really think about what the end goal really is. So in that way, it can be a tool that can help formulate questions you need answered to be able to complete the feature.
I would very much like to use TDD in every instance possible. But how low the threshold is to get started, comes down to, as other have stated, how an application in configured.