Not easy on brownfield, but this is what TDD is for. The spec becomes the tests and you then write code that passes the tests. If business needs change, then tests change first then the code. Writing comprehensive tests is cheaper than rewriting code because the requirements were not well understood.
It usually ends up being other way around. Tests pass because people still don't understand requirements and no one knows what's the issue, than you change tests and make code pass test but in live environment it fails to deliver. Besides as from Uncle B Martin TDD is about architecture not having well tested code. You can find him telling that on multiple occasions but find Jim Complain and him discussing it. For him it's for helping you check what needs to be built how. Last time I did it in C# I ended up exposing too much services and mappers which made it confusing to deliver new features and code was to chopped up. Ended up removing almost all unit tests leaving only ones for calculations and having only sort of end to end test with scenario like approach close to regression test which made much more sense and made architectrue much more clean.
I met too many people disagreeing with usefulness of having a lot of test coverage. Having great QA team that understand clients need beats test for now in my experience.
Still my experience and people I met. I don't think no one benefits from it, just haven't met those people in person.
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.
Not easy on brownfield, but this is what TDD is for. The spec becomes the tests and you then write code that passes the tests. If business needs change, then tests change first then the code. Writing comprehensive tests is cheaper than rewriting code because the requirements were not well understood.
It usually ends up being other way around. Tests pass because people still don't understand requirements and no one knows what's the issue, than you change tests and make code pass test but in live environment it fails to deliver. Besides as from Uncle B Martin TDD is about architecture not having well tested code. You can find him telling that on multiple occasions but find Jim Complain and him discussing it. For him it's for helping you check what needs to be built how. Last time I did it in C# I ended up exposing too much services and mappers which made it confusing to deliver new features and code was to chopped up. Ended up removing almost all unit tests leaving only ones for calculations and having only sort of end to end test with scenario like approach close to regression test which made much more sense and made architectrue much more clean.
I met too many people disagreeing with usefulness of having a lot of test coverage. Having great QA team that understand clients need beats test for now in my experience.
Still my experience and people I met. I don't think no one benefits from it, just haven't met those people in person.