It is a good idea to explore Behavior Driven Development and Acceptance Test Driven Development methods. This post will help you understand how are these two development strategies different from TDD and each other.
The Basics
Behavior Driven Development is a variation of TDD methodology, where in the main focus is on behavioral specifications of the product or application. When BDD is adapted in a project, the technical nitty-gritty aspects of the requirements and implementation are outlined in a business-oriented language.
Acceptance Test Driven Development is a methodology that focuses on the overall collaboration between different stakeholders in a project. It encourages the whole team of developers, QA and business analysts to define the acceptance criteria of an application prior to commencing it’s development.
The Differences
Though the above definitions provide us with a brief understanding of these methodologies, their differences need more exploration.
While TDD is about writing tests to satisfy system requirements as outlined in the BRD, BDD encourages developers to write tests such that they reflect the behavioral expectations from the system of the stakeholders, and not just the functional aspects. BDD uses Ubiquitous language that can be understood by the developers and stakeholders.
ATDD works on the similar lines with subtle differences. In ATDD, the tests are written together with/by developers, testers and customers. Instead of writing up a test case, here, an executable specification is created that can later be run to test the code.
Benefits of BDD
- The tests, and consequently, the code focus on the behavior of a feature thus making customers happy and content.
- BDD helps developers concentrate on designing robust solutions.
- Technical language is given a rest to pave way for better communication and understanding between various parties involved in a project.
- BDD tools such as Cucumber and SpecFlow can be used to generate test scripts from the written test cases.
Benefits of ATDD
- One can create executable specification in line with the requirement the can be refined and run at a later date.
- Testing is moved to the beginning of the cycle thus reducing defects and bug fixing effort as project progresses.
- Testers, developers and business analysts can work together to better understand what is required from the system.
- The focus is on the ‘What’ and not the ‘How’ thus making it easier to meet customers’ requirements.
