Test Driven Development is a key success factor for developing apps which combine functionalities and quality.
We've often spoken about Agile software development and how we've been using this approach for years at DevInterface. A crucial role plays testing in this methodology: let's see what it is about.
As you well know, when you present us a project, we break up in user stories, which will then be allocated inside every sprint. At this point we start developing the app and every developer takes charge of one or more user stories. The Test Driven Development (TDD) starts here: while the user stories are developed, their capacity to satisfy specific requirements is tested. This ensures that your app is perfect.
Starting with the red phase: after defining precisely the characteristics that a specific code part has to satisfy (the user story), an automatic text that verifies the program's capacity to satisfy these functionalities is written. The test will therefore created before the actual software; it follows that initially the test's execution will fail.
Imagine you have to build a house. You know it will need to have certain characteristics: a certain height, width, a number of doors, windows and rooms. Before constructing it, you'll annotate these characteristics on paper and this will be your test instrument. Obviously if you'll try to "execute the test" before constructing the house it will fail because there's still no house.
Then you proceed with the green phase: in this second step the developer writes a minimum code portion, with the only objective of passing the test. Developing other functionalities, as well as graphic or qualitative elements beyond those required is not allowed: the software must function.
As to our house it's time to build the bearing walls of the right height, leaving the holes for windows and doors, outlining the spaces for what will become the future rooms. Now is not the time to think about the colour of the walls or the furniture we will buy to furnish the bedroom. Our house will be ugly to look at, but in our leaflet we can put a nice cross next to the notes, which means that the house will have passed the test.
The last step is the grey phase: at this point one can think of code optimisation, in jargon refactoring. This consists of lightening the code, simplifying it such as eliminating duplicates and so on. At the end of this process tests will be executed again to ensure that the optimisations have not weakened functionalities. .
We can now smoothening our walls to prepare them for the colour application and the insertion of doors and windows, fixing details and small imperfections to prepare the structure for its embellishment. We must be careful not to undermine the previously built load-bearing structure.
In this way we can build apps that fulfil the main requirement: to work. Later we think about aesthetics and usability, both of which are, of course, very important. In this way we can develop fully tested apps, where with the traditional approach (test creation after software development) there would be a risk of developing new functionalities without having completed the main ones; with TDD this danger does not arise because the developers are clear about the objectives from the outset and are also able to estimate the progress of the project. In conclusion, we can say that this path is more advantageous because the developers can even radically change certain aesthetic aspects of the app without the danger of affecting functionality.
Do you think this test-driven approach performs or do you think there are better methodologies to ensure maximum optimisation in app development? Let us know in the comments!
For more information contact us here, or on LinkedIn or Twitter, where you can also follow us to stay up-to-date on our articles.
.jpg)
