DEV Community

loading...
Cover image for TDD success/horror stories? #discuss πŸ™€
Focused Labs

TDD success/horror stories? #discuss πŸ™€

jamesmcmahon profile image James McMahon ・1 min read

I'm curious what the dev.to community's experience is with TDD. Any success stories or horror stories?

Discussion (8)

pic
Editor guide
Collapse
jacklowrie profile image
Jack Lowrie

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!

Collapse
jamesmcmahon profile image
James McMahon Author

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?

Collapse
jacklowrie profile image
Jack Lowrie

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!

Collapse
stealthmusic profile image
Jan Wedel

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.

Collapse
jamesmcmahon profile image
James McMahon Author

That sounds very validating. How did you test the integrations to other machines?

Collapse
stealthmusic profile image
Jan Wedel • Edited

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.

Collapse
recursivefaults profile image
Ryan Latta

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

Collapse
jamesmcmahon profile image
James McMahon Author

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.