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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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!