Automatic Testing

Creating automated tests is a very important element of the software development process.

This approach to creating tests utilizes TDD and BDD methodologies

Both TDD and BDD describe the same model of functionality that was implemented.

Each functionality is created according to a specific scheme consisting of three steps:

1) Creating a test (or scenario) for a desired functionality which initially has a negative result (due to the lack of code implemented);

2) Implementing a desired functionality, by writing code which fulfills the needs of the initial test and then passes it.

3) Refactoring the earlier code.

So what are TDD and BDD and what is the difference between them?

TDD (Test Driven Development) – as the name suggests, this is an approach which describes testing-based programming. In this case, we’re talking about unit tests. We test and implement minor functionalities, which are responsible for individual tasks.

BDD (Behavior Driven Development) – in this case, is functionality based on specific scenarios. The scenarios represent a set of requirements that must be met in order for a given functionality to be considered ready.

In the case of behavioral tests, we test a part of the application in relation to the entire system, whereas unit tests only verify individual tasks.

So how do you apply this knowledge in practice?

The most important aspect of creating any software is the development of User Stories. User Stories, in a literal translation, is the user’s story. Maybe it sounds a bit funny, but that is in fact just what it is. When the required standards are followed, the resulting User Story reveals the client’s functional requirements. As we all know, clients often “don’t know what I want,” or “know,” but can’t explain it.

This is where a User Story comes in.  An important element is documenting the entire ‘history’ of functionality. However, as in every engineering project, this has to be done in accordance with a strict set procedure. Since examples work best, here’s a scenario for ordering a product from an online store:

As a logged in user

When I place an order consisting of products: a TV set and a vending machine

Then a new order will appear in the database with a total price of PLN 2,000.

The User Story, as seen above, specifies: who performs the given action, what the action is and what should happen, confirming that the task was carried out. A well prepared User Story is just a scenario that will be used in the behavioral test in the BDD approach. The keywords in bold are significant. They define the standards – who, what and why the action was taken.

The task of the behavioral test is to verify whether the entire scenario has been implemented correctly. The test will only be ‘passed’ when all the stages have been carried out correctly. If any of the steps ‘fail’ the test, the entire test has been failed.

Unit tests are complementary to behavioral tests. They examine the processes which occur  during the scenario, in great detail. So, in the above example, if a behavioral test is applied and it checks whether the user is logged in, the order was created and the price is correct; then a unit test can be applied to check a specific scenario, such as, the calculation of the gross price of the product.

It’s important to come away with the functionality quickly, so that the general concept of the project can be identified and the details can be filtered out. It’s important to remember that the development of good code is based on good processes (TDD and BDD) and begins with the client’s needs analysis.

A well told User Story allows for the thorough development of behavioral testing, and specific tasks for unit testing. This, in turn, drives the development of the most bulletproof software. Of course, you can’t forget the need for good programming practices like SOLID and KISS (as I mentioned in a previous article), because only ‘good’ code is ready for automatic testing.

You can read more about automatic testing

Good luck!