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 criteria. It is about figuring out what to build with an outside-in approach - having conversations, capturing conversations, automating conversations. In other words, first think about what you’re about to write, then think about how you would test the code, before writing it.
BDD is not an agile project framework (e.g. SCRUM) nor a 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 test cases to get feedbacks, and re-running the same test cases again and again. 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 problem 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. Outside-in Approach
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. When coding, first think about what you’re about to write, then think about how you would test the code, before writing it.
2. Specification by Examples
In order to <why>
As a <type of user>,
Scenario Name: ...
Story: Returns go to stock
3. Developing and using a ubiquitous language
Use a common, rigorous language between stakeholders (users) and programmers (developers) so the same thing is called using same right words. Emphasis on collaboration, and the use of business-readable, executable specifications. When everyone is involved in writing living 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.