When developing an application, developers need to also write tests in order to ensure that their code functions properly. These tests will be run automatically, all throughout the development process. Using them also stops new bugs from appearing in the code.
Below is an overview of these tests, as they apply to Mobapi’s software development work.
Why do testing?
Testing has developed a lot over the past few years, to the point that tests have now become indispensable in the development of software. Using them has numerous benefits that will be described below.
The first benefit that tests provide is to guarantee that the code works, meaning it efficiently produces the thing that we want it to produce. That’s the first goal of any test!
Running tests also injects a dose of rigour into the project: code that’s been tested is code that conforms to the expected requirement.
What’s more, when tests are well-written, they serve as documentation. This leads to better comprehension of the code and of its functionality by other stakeholders.
Tests are often designed using a continuous improvement approach: each time a developer modifies the application code, the tests are launched and run.
This allows each developer to be sure that the modification that she or he introduced did not negatively affect the old version of the code and did not create any new bugs.
So in this way, we avoid regressing.
In summary, employing testing on code allows applications to be developed more rapidly, and with more certainty.
How does it work?
When we talk about tests, in reality there are several levels of them:
- Unit tests allow code to be tested at the lowest level, by isolating each part of the code. These are indispensable and make up about 80% of all tests overall.
- Integration tests are there to verify that correct functioning is taking place between various different parts of an application. These make up about 10% of testing.
- Functional tests help developers confirm that user interactions with the application are working correctly, for example the action generated by clicking on a button or a link.
Two methods exist for organizing the development of an application around testing:
- Test-Driven Development (TDD)
- Behaviour-Driven Development (BDD).
These two methods are very commonly used because they save time during the application’s coding phase. Using these, developers avoid writing functionality that is not strictly necessary.
The principle of TDD is to write the test before writing the code. Yes, that does mean anticipating something that doesn’t yet exist.
The developer writes the test, which is obviously then going to output an error. Next, he or she writes the code so that it passes this test, no more and no less. The entirety of the code is developed while thinking primarily about the tests.
The BDD method, for its part, is derived from TDD. The difference is it creates a language that is comprehensible to all of the actors involved in the project: developers, project managers, sales reps, etc.
This involves the use of frameworks more or less oriented towards one or the other method. Technically, this is demonstrated via a syntax that is reasonably close to “human” language.
Typically, a test written under the TDD paradigm would give something like the following:
When we follow Behaviour-Driven Development, we read the tests like we would read a text written by a human, meaning that it is much more legible as compared to TDD. For example:
At Mobapi, our developers devised tests for all levels of the application. For example, here is a screenshot of what happens when a developer modifies the application’s source code to update the code:
All of the tests have been passed successfully, and the developer has not changed the functioning of the original code, and so can move on to the next stage of the work.
Thanks to this article, I hope that you now understand why we decided to incorporate the formidable tools known as tests into our work. ;)