Developers need to test their code! This is a certainty and an obligation. Like everyone involved in the project: developers, product owners, business, etc. Everyone, at some stage, will have to take part in a test phase. And everyone will have to perform certain types of tests following the level of testing.
Why do developers have to test their code? Mainly to make them more responsible for their work. They will produce better code by being more involved.
But how can they effectively test their own work? How can they be honest in their testing?
Developers have to do 2 types of tests to verify the maximum quality of their work. This way, they can guarantee that the system will work appropriately according to the technical specifications. The first testing type is the component test. The second type of test is the code review.
#1 Unit or component testing
The component is the smallest unit in a code set. It represents a part of a program. The purpose of component testing is, therefore, to verify proper operation as specified in the technical specifications. Component tests are also called unit tests. Tests are done at the code level. Developers, therefore, take charge of component testing.
Most of the time, unit tests are subject to development scripts so that they can be played at each delivery.
For many years unit testing is often seen by developers as secondary. And in projects with constrained (or no) budgets, it often falls by the wayside. Which is, from a quality point of view, a grave mistake. The earlier you test the system, the less expensive it is to test. Confidence in the quality of the software is more important. Subsequent test phases are faster and less stressful.
Development methods such as Extreme Programming (XP) or Test-Driven Development have understood this. Unit tests are at the center (and especially at the beginning) of the development process. First, you write the test, and then you run it. So it fails. Then we develop the function so that the test passes. So quality is a significant and constant concern for developers.
#2 Code review or peer review
Code review is an examination of the code by the various developers working on the project. As with unit testing, the objective is to find design bugs as early as possible to intrinsically improve the quality of development. And once again, even if the notion of code review has been known for a long time, it is rarely implemented by development teams.
Once again, with extreme programming or agile methods, code review becomes an essential element in the software qualification process again.
Code review is particularly efficient. Knowing that his code is going to be reviewed by a third party who is himself a member of the team, the developer will commit himself to a self-review. As when one rereads a text, rereading one’s code allows one to correct the primary defects.
Software exists to help in this task, such as SonarQube. But in my opinion, delegating all or part of this work to an automaton is partly questioning the foundations and benefits of code review by one’s peers. The developer will read his code less. He will be less involved in the quality of the code because delegated to a machine. We’re back to the starting point.
In conclusion, even if developers should not test everything, they are the leading architects of software quality. Implementing these 2 good practices in your development projects will ensure, among other things:
- Better code quality;
- Easier maintainability;
- Reduced development costs;
- Optimize the budget allocated to testing;
- Reinforce team cohesion.
