TDD offers benefits in terms of both project/work dynamics and software quality. Some benefits are obvious (feedback from tests) but most are not (small steps lead to a higher frequency feedback loop and more control). One view of this is that some benefits come as a by-product.
TDD / BDD (I'm going to use BDD from now on, substitute as you see fit) gives testability as by-product. This is basically the view expressed by Jungmayr.
The simplicity of the BDD method makes it general, flexible and adaptive. The flipside to that flexibility is that there is ample room for misunderstanding.
Does BDD prescribe testability? No. Indirectly, your designs *should* become testable if developed using BDD. However, there is no "step four" (after RGR) that says "review code for testability or maintenance issues and fix them". It is often not part of refactoring since testability affects design and "unit" (usually class, YMMV) functionality may indeed be altered.
Instead, BDD infuses many testability, maintainability and other factors of high quality software, through its focus on testing one small thing at a time, "small-scale tests", and eliminating duplication. In order to test just that one thing you must figure out a way to replace what it interacts with. You must be able to manipulate the link between them; you must make the dependency "loose". The consequence of this is that all classes will depend on each other loosely. They will not have hardwired dependencies.
Hardwired dependencies are when class A is coded to always use class B. This may be since it A itself creates B or uses static methods of B.
This makes the code less testable since there is no direct way to test a part of the system, by manipulating the dependencies. We have to use other means, via a more complex test harness, and/or tools.
So testability comes as an indirect result. But can we say it is a byproduct? Is it true that this is not a systematic way to get testability in our code?
Even though most misunderstanding is a product of ignorance, would there be a way to make TDD more explicit (in how benefits are addressed) by design? I am unsure, I agree with the idea that understanding in the form of realization is often impossible to transfer. It has to be experienced to materialise. Often, the best that can be done is offer guidance and direction, a map to where the realization of knowledge lies. The question then becomes if the benefits require such realization or can be reduced to following a systematic approach.