BDD is a QA concern, primarily used for QA tests against a written (BDD) requirement.
TDD is about unit testing, which is about testing the implementation BY developers FOR other developers.
TDD says nothing about the correctness of the software against a spec, only that a given implementation aligns with a developer's intention.
If they are, the only difference between TDD and BDD is where, in which form, and by whom is that behaviour defined.
Say it with me, unit tests are to aid refactoring.
If we mix QA and implementation details just because both sides use the word "test" it ends in trouble.
QA should be blind to unit test coverage or even usage at all, they're totally independent concerns.
A passing unit test says nothing against correctness of product against a spec or design... only that it works and continues to work as a developer intended, to aid the work of future developers, even if they misunderstood the spec.
Your comment is at the core of why QA is a total mess. Everyone is confused about what "test" means in different contexts.
Why have a QA function at all with 100% unit test coverage? Because the unit tests may encode misunderstanding by developers. They're there to fight entropy, not wrongness.
QA, using BDD and other tools, ensure the product is correct, regardless of how well it fights entropy by unit tests.
Tests in general can only help you refactor code at a lower level of granularity than what you are testing. Something lower than unit level is a contradiction.
Of course, you can instead test business behavior which isn't as volatile in refactoring and change your definition of unit to be a unit of practical business requirements...
But a developer looks at f(a,b) and realises a new implementation could be 10x faster.
The developer re-writes the function, the tests still pass. Without that test they couldn't be sure their rewrite didn't break the expected behaviour.
What you're talking about is changing interfaces and structure when refactoring. Yes, unit tests can make that more painful. But you bin your old tests and write new ones.
If your unit tests are not cheap to dispose of, run or rewrite ... that's your core problem.
If your unit tests are not testing discrete units, instead testing the combined behaviour of many units (the re-factoring of structure pain) ... then you have bigger issues than the tests; namely understanding the difference and applicability between unit and integration tests.
Particularly the important differences between unit, integration, and e2e testing. Many people use the words interchangeably when they are completely different concerns.
Unit test your library code that has no external dependencies, integration test your classes that implement those libraries, and e2e test your application that is built with those classes. There are varying philosophies to which are more useful, but it's an important distinction to maintain in terminology.
