In order to improve the quality of developed software, every day more solutions oriented to the two most used development techniques: TDD (Test Driven Development) and BDD (Behaviour Driven Development) appear.
One of these kind of solutions is Karma, a powerful tool that integrates with different frameworks (Jasmine, QUnit, Mocha, etc.) and is responsible for executing the Javascript tests as they're built, allowing us to verify that the application works and helping us identify potential problems.
We will deepen more on Karma in future posts. In this occasion we want to offer a brief overview on the possibilities of integrating different tests in our test cycle.
First, the definitions
TDD (Test Driven Development) is a programming practice that consists in writing tests first (usually unit ones), then writing the source code, and finally, refactoring the code written. With this practice, among other things, a safer, more robust and more maintainable code is achieved, and also the development becomes faster.
There are many benefits of following the ideas of TDD but mainly it helps us think about how we want to develop functionality, allowing us to make a more modular and flexible software, minimizing the need for a "debugger" and of course, increasing our confidence when changing to the application.
But either for not fully understanding the philosophy, or for wanting to take it to an extreme, it also has its flaws:
- Difficulties trying situations where functional or integration tests are necessary.
- It is difficult to introduce TDD in projects that have not been developed from scratch with this methodology.
- To be really effective it is necessary that the entire development team use TDD.
- Sometimes unnecessary tests are created, causing a false sense of security.
To try to solve some of these problems, other techniques such as BDD and ATDD appear.
BDD (Behavior Driven Development) is a process that widens the TDD ideas and combines them with software design ideas and business analysis ideas to improve software development. BDD is based on the best practices of TDD and emphasizes them.
By using BDD we do not test just units or classes, we test scenarios and behavior of the classes in meeting these scenarios, which can be composed of several classes. Now well, it is important to note that when carrying the BDD practice is highly recommended to use a DSL instead of a natural language, which gives us a common language on which to do the test and thus reduces friction when sharing the test.
All this serves us to check the internal behavior of the application. However, once the functionality is ok, is the acceptance test turn.
ATDD (Acceptance Test Driven Development) are those tests intended to determine whether certain functionality requirements have been achieved.
In this case the entire team should discuss acceptance criteria with examples, and then divide them into a set of acceptance tests before development begins.
Finalizing
The main difference between TDD and BDD is the scope. TDD is focused on how the code is written and how it should work, while BDD is a team approach that focuses on why the code should be written and how it should behave. In the case of ATDD, it is closer to BDD. In fact there is a debate about the real difference between this two methodologies. Anyway, the mainly difference is again the scope.
In short, all these methodologies are useful. As we have seen BDD gets the best practices of TDD and tries to guide the developer when choosing which parts of the application should be tested. All this, added to the acceptance test, can help us prioritize development that really adds value to the user.
