TDD will leave you with a load of tests which prevent you from changing the code. BDD on the other hand should leave you with a suite that isn't coupled to a specific implementation.

Part of the information contained in a test is the intent of the verification being performed, and part is code for mapping that intent onto the implementation. The latter part can be discarded during a rewrite. Cucumber/SpecFlow etc. make the difference between these explicit.

> and part is code for mapping that intent onto the implementation

Wait, what?! The more I listen people talking about TDD, the more I discover I always misunderstood it, and the less I want to actually understand it.

The thing is, unit tests that are affordable to implement, are not wort it. Their objectives should rather be verified with language choice, programming techniques, and assertions. Tests that are worthwhile to write are those that test interactions of multiple subsystems. But those are not unit tests any more. If you end up _actually needing_ TDD, then that proves you are using the wrong language and/or the wrong technique.