BDD is basically TDD done properly. It is an approach for building a shared understanding on what software to build by discussing examples. It is a technique that uses a business language to define acceptance of requirements. It is about figuring out what to build. BDD is not an agile project framework (e.g. SCRUM) or project management approach.
Software testing involves the followings:
1. specification - Define problem domain we'd like to solve.
2. feedback - Run test and see if the code works.
3. regression - Once it works, it should continue to work, so we run all testcases again to make things still work.
When I got my first gig as a junior software engineer in the 90's, I also did QA works that involves coming up with test cases according to the specification, running the tes tcases to get feedbacks, and re-running the same test cases. When I reported bugs, the test cases reflect an extra aspect:
4. granularity - When things go wrong, what went wrong? We'd like to get more information when tests failed.
As far as I can see, there are two pain points in software development with respect to testing:
Discovery problems late in the process is expensive because cost of change goes up as time moves on. To lower such cost, we want good communication between people in the program domain (stakeholders who have problems) and people in the solution domain (programmers who implement solutions) to have less problems. For the problems, we'd like to be more agile in fixing the problems in the software. For this, we need to make code cleaner by applying refactoring.
Good habits introduced and emphasized by BDD are:
1. Working outside-in
Define behavior we want before we implement that behavior. Talk to domain experts first and code second. Starting from a business or organisational goal, having the requirement challenged, working from business-level to the code-level testing. It’s much cheaper to understand the spec out before you write the code.
2. Using examples to clarify requirements
In order to <why>
As a <type of user>, I want <some goal> so that <some reason>
Story: Returns go to stock
3. Developing and using a ubiquitous language
Use a common language between stakeholders and programmers so the same thing is called using same right word. Emphasis on collaboration, and the use of business-readable, executable specifications. When everyone is involved in writing documentation that describes what the system should do, they all get a chance to learn the language of the domain together.
BDD vs. TDD
BDD really isn’t all that different to TDD. What BDD adds is a clear emphasis on what it takes to make TDD succeed: Focus on value. Discover examples collaboratively. Create living documentation describe the behavior that continue to be true.