If you want to understand the history of Behavior Driven Development, you should probably start from the introduction by Dan Terhorst-North, first published in March 2006.
I decided it must be possible to present TDD in a way that gets straight to the good stuff and avoids all the pitfalls.
My response is behaviour-driven development (BDD). It has evolved out of established agile practices and is designed to make them more accessible and effective for teams new to agile software delivery.
Does behavior driven development work on the level of writing individual unit tests for a single unit. Or is it actually more closely related to integration testing, crossing over multiple units?
These communities didn't use a definition of "unit test" that was clearly in alignment with the definition(s) used by the testing community.
As far as I can tell, Beck's tests have always played a little bit loose with how many "units" are being evaluated. More important was the idea that the testing step be quick, and therefore test design pays attention to isolating tests from one another, and making sure that test execution didn't depend on any elements that were slow or unreliable.
Boris Beizer, in his books on testing, refers to tests with multiple "units" as "component tests".
You also find alternative definitions of unit that emphasize deployment - "unit" might be an entire package, because that's the "physical" thing that you can actually pick up an move around.
How do you write behavior driven "unit tests" for low-level modules such as a memory access module or a component driver if that low-level component doesn't provide any business value on its own?
You do one of two things - you design your tests with known good components interacting with your low-level test subject, the "unit-test" approach; or you test a cluster of unverified units together.
The nature of the test itself, as far as I can tell, doesn't change very much. You do end up, perhaps, with more "fixture" code than you would need when measuring higher level components.
(As far as I know, none of the characters in these stories are bringing a lot of low-level experience to the table. I'd recommend looking into James Grenning's work
Then, in the other direction, how do you write behavior driven "unit tests" for a single high-level component if the business requirement can only be validated when integrating low-level modules and can't be validated using mocks of the low-level module?
It turns out that nobody is awarding prizes for "unit tests", of any definition.
If your tests catch your mistakes less than a minute after you make them, the label doesn't matter. All you care about are the constraints introduced by that "less than a minute" requirement - you need to be willing to run the tests often, and that means that they have to be reliable, and quick enough to not be a distraction, and ... and ... and....