One of the biggest "aha"'s I've had was when working on a legacy codebase with very few unit tests.
I needed to change the behavior of a couple of methods, but I wasn't super sure what their current behavior was to begin with.
A lot of folks would reach for their debugger and spend the next while meticulously stepping through the code. But that felt slow to me...
So I put together a suite of tests around them (prior to making any code changes) to verify and document what they were really doing. Once that was done, the overall change was as simple as adjusting a couple of assertions, causing those tests to fail and reimplementing the methods to meet their new expectations.
It's one thing to see TDD as a way to confidently write a brand new feature, it's a whole other ballgame to see it as a way to confidently navigate and tease apart legacy code. It was like being in a super dark tunnel, and finding a flashlight. Literally everything got easier.
And don't even get me starting on working on an old codebase with a good suite of tests. Pure. Bliss.
Same here. Was implementing an embedded client of a client/server system. I did write tests but not TDD. Then, our backend developer left and I needed to take over the code. It was a complete mess, it was slow, Spaghetti code and no tests. Developer horror story. Then I wrote test by test to freeze the current behavior, found and fixed tons of bugs and threw away half of the code after refactoring.
From that moment on I was in love with TDD. The next project I did was all TDD: Zero bugs in production.
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.
One of the biggest "aha"'s I've had was when working on a legacy codebase with very few unit tests.
I needed to change the behavior of a couple of methods, but I wasn't super sure what their current behavior was to begin with.
A lot of folks would reach for their debugger and spend the next while meticulously stepping through the code. But that felt slow to me...
So I put together a suite of tests around them (prior to making any code changes) to verify and document what they were really doing. Once that was done, the overall change was as simple as adjusting a couple of assertions, causing those tests to fail and reimplementing the methods to meet their new expectations.
It's one thing to see TDD as a way to confidently write a brand new feature, it's a whole other ballgame to see it as a way to confidently navigate and tease apart legacy code. It was like being in a super dark tunnel, and finding a flashlight. Literally everything got easier.
And don't even get me starting on working on an old codebase with a good suite of tests. Pure. Bliss.
Fantastic example. Sounds like a great way to both help you understand what exactly the code is doing, document it, and keep it safe for future devs.
Can't say I've ever taken this approach before, but I'm gonna try it out next time I'm working on modifying some legacy code.
Same here. Was implementing an embedded client of a client/server system. I did write tests but not TDD. Then, our backend developer left and I needed to take over the code. It was a complete mess, it was slow, Spaghetti code and no tests. Developer horror story. Then I wrote test by test to freeze the current behavior, found and fixed tons of bugs and threw away half of the code after refactoring.
From that moment on I was in love with TDD. The next project I did was all TDD: Zero bugs in production.