I think there is quite a big difference, fundamentally, between BDD and TDD (though they are not mutually exclusive and do overlap). Let's try a quick example

I think there is quite a big difference, fundamentally, between BDD and TDD (though they are not mutually exclusive and do overlap). Let's try a quick example of a google maps type app: locating where you are and where you want to be. From BDD perspective, you get a mockup of the screen (could even be some non visual process) and this represents the behavior you want of the product: the behavioral requirements. From this mockup we can pull out all the behavior on that screen (or within that system). Feature: In order to see if I am where I want to be As a traveler I need to know my location. Scenario: At My Location Given I want to be at Lon XXXX Lat YYYY And I am at Log XXXX Lat YYYY Then I should see "You are There" Scenario: Not there Yet Given I want to be at Lon XXXX Lat YYYY And I am at Log XXXX Lat YYYY2 Then I should see "You have 4 meters to go". From this behavior we can then build out the system which inevitably leads to fine grained software specific behavior which should be tested using TDD such as: it should "calculate the distance between two points correct" In the case of BDD, we don't worry about how the two points are calculated nor if it is even done correctly (we don't need full fringe test coverage in BDD). We are able to assume that the underlying calculations will be correct. We do need to make sure that the behavior of the system as a whole is working correctly. In this case, we are assuming if the calculation is incorrect we will not see "You are There" on the screen. Why was it incorrect? Doesn't matter. That specific behavior, the calculation, was driven by Tests. Personally, and for efficiency, it is really important to use both in a project and not look at BDD as "TDD done right." Just my two cents.