There are two relatively similar terms in the world of automated testing that have come back to the forefront with the Devops and Software Craftsmanship approach: ATDD and BDD (behavior driven development).
Automated Functional Scenarios (BDD)
The BDD (behavior driven development) is a type of automated functional tests written with a natural language understood by everyone called Gherkin; it is the product owner (or trade representative) who does this work.
It’s not easy to automate tests; the BDD favors the given-when-then instead of the classic format of user-stories. The format of the user-stories doesn’t make it easy to control the setting up of tests.
Here is a simple example:
Given I am a customer on a product sheet When I add a product of login "2345" to the shopping cart And that this product has a stock of "5" Then the product is added to the cart
Then a tool will transform this functional test written in natural language often put in a .feature file to make empty code functions to be filled by the developers.
The author of this approach, thought that the tests carried out with the TDD were not enough to obtain an optimal quality and to ensure 100% of the future non regression. Being an extension of the TDD, the BDD recommends that developers write the test before writing the associated code.
Recall of the TDD cycle:
- Write the unit test
- Launch it and check that it fails (class not yet coded)
- Write the class to test with the minimum to run the test
- Start the test and check that it works
- Finish the complete class code
- Check that the test is still working (non-regression)
For the ATDD, it is possible to write the test using the same natural language upstream but this is not mandatory. The developer can write the code of the functional test directly without going through the “natural language”.
The main idea of the two practices ATDD and BDD
The ATDD (Acceptance Test-Driven Development) aims to write the functional tests before even coding the functionality; it is the functional tests that will guide the technical creation of the functionality.
This practice is very close to the TDD (Test-Driven Development) which aims to write the unit tests (increments).
The ATDD offers a work cycle to the developers very close to the one we have in TDD with the addition of the presence of the client:
- Define the test with the client
- Write the functional test
- Launch it and check that it fails (feature not yet coded)
- Write the functionality to be tested with the minimum to run the test
- Start the test and check that it works
- Finish the complete code of the feature
- Check that the test is still working (non-regression)
The BDD (Behavior Driven Development) presents a practice that purposes to the product owner (or customer representative) to write the functional tests in order to indicate to the developers the expected behaviors.
Indeed, the idea is to remove any misunderstanding between business owner (or representatives) and developers; it’s not just for the sole purpose of writing a test.
The ATDD and the BDD are two similar practices
If the ATTD is a software engineering technique despite the presence of the client for the definition of the test, the BDD purposes that the behaviors are piloted as soon as the requests are written to help the technical team in the expected by the key users.
These are very similar practices in reality. However the philosophy differs on the moment of the definition of the tests.
Conclusion BDD and ATDD
These two functional test practices (ATTD and BDD) are different but are very close. However the philosophy around the implementation of these tests is different.
This is also the reason for the term “Behavior” which talks about behavior (which drives applications until their realization) and “Acceptance Test” which talks rather about the implementation of an acceptance test where the client comes to assist the technical team for the implementation.
Do you do this type of testing within your company?
3 Trackbacks / Pingbacks