Development: Test Driven V Behavioural Driven (Tdd bdd)
In the world of software development, the binomial tdd bdd is often mentioned. The acronym TDD stands for Test Driven Development, a developmental process based on the use of automatic tests. These must be carried out before the testing of the software itself, which must also undergo testing procedures.
It is essential that software development should be oriented towards passing specific automatic tests, already designed for this purpose. It is also important to remember that TDD is divided into four parts: analysis, design, development and testing.
In other words, the developers observe the problem area and analyse it, in order to identify the most suitable applications to resolve it. Of course, these apps must also undergo a testing procedure.
The process is completed by following these steps:
- Writing up a unit test designed to fail: at this stage the results of the developer’s work must be as simple as possible. It is essential that this test is designed to fail. The developer must in fact show how the code should not behave.
- Execution of the test: when the testing procedures fail, it is time to write the minimum code necessary for them to pass. During this phase, it is crucial that new elements should not be added.
- Improvement of the test: the developer who believes that he can further improve the code he has written can do this and carry out new tests. Once an optimal result has been reached, all that remains is to start creating new unit tests and continue from there.
Featuring advantages involving the opportunity to re-use code and work in groups, TDD often contrasts with BDD, the acronym for Behaviour Driven Development.
What is Behaviour Driven Development?
Now let us consider the other end of the binomial tdd bdd, Behaviour Driven Development. Belonging to the agile development philosophy, it is aimed at optimising communication between professionals working on a specific development project.
During the BDD process, the functionalities are described according to so-called user stories. These consist of:
- A textual description designed for use during the planning stage or as a reminder.
- A conversation aimed at giving further details of any aspects requiring clarification.
- A test designed to check if the story is complete or not.
It is essential that the description should be concise, written in a natural style and remain relevant to a specific functionality. It is also very important that it should not contain any technical aspects.
Once the story has been completed, it is time to focus on possible scenarios for the operation of the functionalities. The scenario of the individual user stories constitutes the actual acceptance test to be considered once the development of the functionalities is finished.
Three stages must be considered when dealing with the description of the scenario, which may be summarised using the terms ‘given’, ‘when’ and ‘then’. In detail, these are:
- Given a specific context (given)
- If a specific event happens (when)
- A specific thing must happen (then)
During the given step, all technical stages required for the system to achieve the right status for the test to be carried out are included. As regards the when step, a user-prompted event must take place, with the purpose of operating the functionality under examination.
Finally, the then step, which is essential to gain an understanding of the second part of the binomial bdd and features a description of what happens in the system, with the focus on significant reactions by a single application. During that phase, the developer finds out if the test has been passed or not.
Translated by Joanne Beckwith