What do we lose when we don’t write tests for our code? (2024)

This issue is common among new developers, who are not confident and often not even bothered about writing tests for their own code. Despite the fact that test cases are a crucial step of the software development lifecycle, most developers are naturally inclined to bypass this process since it reduces overall shipment time. However, the fewer tests we write, the less stable our code becomes. This subsequently impacts productivity and accuracy for future developments, and increases pressure to deliver high-quality software with agility.

Below are some of the challenges encountered by developers when writing tests:

1. Lack of knowledge about writing tests.

2. Monotony while writing tests.

3. When writing tests, developers often fail to meet their delivery deadlines.

4. The process of writing tests is time-consuming.

5. Writing tests often feels like an optional process, especially if the code is running well.

Rather than discussing what tests are and their implementation, this article mainly focuses on the importance of writing tests and what may be lost in the absence of tests.

Let’s take an example of two people named TestPerson and CasualPerson. Both are developers writing code for the same company, following a structure of moving their code from the development environment (internal to software engineers) to the production environment (end product available to customers/users).

An ideal software development process would look something like:

1. Writing the Code.
2. Getting the code reviewed by fellow software engineers.
3. Handing over the code to the Quality Assurance Team (QA) so that they can test it in real-world scenarios.
4. Pushing it to the production environment for end users.

CasualPerson writes the code, gets his code reviewed and pushes it for QA. QA tests his code, finds some bugs and reverts to the engineer.

CasualPerson modifies his code, makes some changes and then again sends it back to QA, thinking he has fixed all the issues. But in turn, QA finds that new issues were fixed but things which were working previously got broken, which gives it out for another round of iteration. The iteration continues until every bug is fixed.

1. Multiple rounds of iteration back and forth between the developer and QA.

2. A lot of time is wasted in QA cycles.

3. QA lost their confidence in engineers as they kept on testing things which were tested earlier and were working fine.

4. Engineers lost their self-confidence in sending their code to QA in fear of discovering more bugs.

5. Deadlines are not being met.

In a second scenario, here is how TestPerson works and handles all these issues faced by CasualPerson.

TestPerson begins by writing the code, as well as writing tests for his code to ensure everything is working well. TestPerson then gets the code reviewed by fellow software engineers before handing it over to the Quality Assurance team. There is one major difference here from the CasualPerson’s process, which is writing tests for his code. When the code reaches the QA they do a thorough testing and find some bugs. But in this case TestPerson can now only focus on the reported issues and doesn’t even need to take care of the other working features, because this would be handled by the tests he has written. TestPerson can now know even before handling his code to QA if there are some issues with his code or introduced by the new changes he has committed to the code.

1. Reduced QA iterations.

2. Reduced time taken in QA cycles.

3. QA developed a sense of confidence in the engineer.

4. Engineer has confidence in his code before pushing it to the QA.

5. Far more practical to achieve project deadlines.

We should write tests in every sort of manner, aiming for the long-term goal instead of thinking for the short-term goal.

Testing is an important aspect of software development, it is there for a reason and this is why exceptional developers always tend to have this included in their stack. The main goal of testing is to segregate each part of the program and test that the individual parts are all working correctly. Testing isolates the smallest piece of testable software from the rest of the code and determines whether it works exactly as it was intended to. Testing has continuously proven its value, since a large percentage of defects are identified during this process.

Writing tests for code is very beneficial in the software development lifecycle and this can be seen in the breakdown below.

Testing goes hand in hand with agile programming, because it builds tests that allow you to make changes more easily.

Since testing is carried out by developers, where they test individual code before the integration, software bugs can be discovered very early and can be fixed there and then without affecting the rest of the code.

Testing improves the quality of the code, seeing that it identifies every defect that may arise before the code is sent further for integration.

Testing allows the programmer to refactor code or update system libraries at a later date and the module would still work correctly. Testing verifies the accuracy for each unit, hence reducing defects in the newly developed features.

Hope you all like it; look out for our next blog until then.