I don't see any reason not to use BDD with legacy code. You could even use the TDD approach of writing specifications for any defect, before writing the code to fix it, and for any enhancement, before writing the code to implement the functionality.
If you've got some time, it wouldn't hurt to write some specs for the primary behaviors of the system. It will help consolidate everyone's beliefs about how the system should behave and give new team members some documentation they can trust because it's executed regularly so they know the system behaves the way it's described.
My two cents,
SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
I agree with Burk. BDD (like TDD) works great with legacy code. Though retro-fitting unit tests to legacy code is generally a thankless task. For mission-critical code you can use it at a high level, as if you are writing technical specifications for your code base. Start with the most important code and work out.
And for trouble-shooting, writing BDD-style unit or integration tests is a way to clarify and document your assumptions about what is causing a bug, reproducing it, and then ensuring that it doesn't happen again.
Some great advice so far.
Just to add another point, whether you use TDD/BDD for legacy code, it is likely that your biggest challenge will be actually making your code testable.
Joined: Oct 01, 2001
Nic Grange wrote:Just to add another point, whether you use TDD/BDD for legacy code, it is likely that your biggest challenge will be actually making your code testable.
Yep. That's a biggie, but Michael Feathers wrote a great book on it called "Working Effectively with Legacy Code" It's an older book (2004) but still in print and you can pick it up from Amazon. It's chock full of great ideas on how to work with legacy code and is well worth the money.