Do you truly value unit testing? Is it wise to divert the team’s attention from development to enhance the codebase? Developers often find the repetitive process of examining code, simulating data, establishing test group(s) and their function signature(s), composing tests, and then revising existing code to be tedious.

Furthermore, managers have to balance team resources against the expenses of implementing unit testing. Limited project scope, due to factors like a small team or time constraints when facing deadlines, and budget limitations are among the primary reasons for forgoing unit testing.

However, integrating unit tests can be as simple and beneficial as verifying the freshness of milk before adding it to your coffee. Ultimately, unit testing undoubtedly improves a project’s development process and reduces costs, as we’ll discover while exploring its advantages and common implementation strategies.

Advantages of Unit Testing for Your Projects

Unit testing involves running targeted tests on small code segments (units) to ensure proper functionality during app development. Detecting errors early through unit testing minimizes debugging time and saves money.

Reduced Costs After Production

Integrating unit testing into the development process enhances your application’s quality. The app is delivered with fewer defects for QA engineers to report or developers to fix.

A lighter post-production workload translates to lower project costs and faster completion. Managers can adjust budgets and schedules by shortening QA team contracts, starting subsequent projects earlier, and developers can begin work on new apps sooner.

All of this contributes to further cost savings. It’s reassuring to know you’ve taken steps to prevent potential issues.

Increased Earning Potential

A high-quality, bug-free application experience leads to more satisfied and loyal users. If users recommend the app through positive reviews or by sharing it with others, its earning potential grows significantly.

The absence of negative reviews also contributes to financial success. Just as some consumers seek positive feedback, others actively look for negative reviews to avoid problematic products. (I belong to the latter group.) Arguably, from a business standpoint, attracting positive reviews is beneficial, but avoiding negative ones is crucial.

Stopgap Documentation

Examining unit tests can help new developers understand an application. When a project is divided among isolated teams, reviewing unit tests helps bridge knowledge gaps and provides insights into the overall application.

Regardless of a team’s structure and communication methods, reading unit tests allows developers to gather information that might be poorly documented or hidden within extensive notes.

Natural SMART Goals

Unit testing inherently breaks down a project into manageable, well-defined units. These individual code sections effectively become clear SMART (specific, measurable, achievable, realistic, and timely) goals.

Achieving SMART goals benefits a project by making progress transparent to leadership and stakeholders. Developers are encouraged to plan and code systematically. Each code unit has a single function, which is tested for proper operation. The code adheres to the separation of concerns principle:

1. Each project unit serves a single purpose.
2. Each function within a unit operates within its designated scope.

Having smaller units makes project tracking easier. Compared to a team with unclear or distant milestones, a team consistently completing units is likely to be more content.

Improved Scalability

Well-designed unit testing affects code scalability in several ways, enabling us to:

Testable code is clean, modular, and reusable in other environments.

Stable Code and Features

Imagine we have a tested and implemented global search-by-name feature, and now want to add result filtering for the user.

We would create a new unit for the filtering function. We can be confident that the global search-by-name unit will still pass retesting. The new unit’s code shouldn’t affect the functionality of other units.

Enhanced Debugging

Identifying and resolving the root cause of a bug is simpler in unit-tested code. If the search feature malfunctions, instead of searching the entire codebase, you can review unit test results in the project’s search module.

Efficient Refactoring

Unit testing a feature ensures it works as intended, even after refactoring code logic or updating external libraries.

Returning to the global search-by-name example, suppose it works perfectly but is slow. We implement a potential fix (e.g., algorithm replacement) and retest. We can be confident that we haven’t broken the previously tested feature, as it should still pass its unit tests.

Unit Testing Strategies

There’s no single standard for testing. In fact, there’s much discussion among experts regarding the amount of unit testing required for project success. There are trade-offs between time investment and code quality. Once the scope of unit testing is determined, the project manager must choose from various strategies.

Unit Testing Scope

Think of unit testing as an insurance policy for your project. Often, an individual’s risk tolerance dictates the coverage amount or the extensiveness of the unit testing plan. Some prioritize maximum coverage to prevent disasters, while others are willing to take risks, perhaps due to their ability to recover from potential setbacks. Most people fall somewhere in between.

A unit testing plan’s scope typically falls into one of three patterns:

• Testing the entire codebase sequentially.
• Testing the entire codebase based on importance.
• Testing only critical parts, maximizing the testing effort’s impact.

The third pattern, targeted unit testing, is often the most practical considering project constraints. It involves selectively testing crucial code sections for project success.

Software developers are well-equipped to determine appropriate tests based on their understanding of each code snippet’s purpose. Returning to the coffee analogy: with limited resources, most would agree that checking the perishable milk is more crucial than checking the shelf-stable sugar.

After deciding on the scope, we need to select a suitable strategy.

Unit Testing Approaches

The industry standards are:

• Post-implementation testing: Developers write tests after implementing features.
• Test-driven development (TDD): Developers write code and tests concurrently for each feature requirement.

Post-implementation testing might appeal to managers who prioritize rapid development to meet deadlines. Consequently, it’s more prevalent than TDD, which starts slowly and demands discipline and patience throughout the project.

Both approaches share similar steps but differ in their order of execution. This table outlines these steps, highlighting the identical ones in both approaches:

It’s important to mention hybrid unit testing, where features are tested post-implementation, and bugs found during development are fixed using TDD, with tests added for each new bug.

Technical Examples

We’ve discussed different approaches, but how do we prepare a project for clean, distinct unit testing in practice? We start by implementing a separation of concerns, ensuring each unit has a single objective and each function performs a single task.

Only a unit’s interface should be tested, excluding internal states and properties intended for access by other units. For a unit responsible for multiplication, we would test its accuracy (e.g., 5x7=35) but not its internal workings (e.g., 5x7 vs. 7x5 vs. 7+7+7+7+7).

Imagine an application that displays three text files with blue headings. We start by writing the entire feature code, loading files, and displaying headings using best practices and separation of concerns. We then test and refine the code.

With the code implemented, we define test cases to verify the entire feature:

1. Do the files load correctly?
2. Is the file text displayed?
3. Are the headings in blue font?

Next, we write separate unit tests for the corresponding code units:

1. The file-loading function.
2. The text-displaying function.
3. The formatting function.

We can examine these scenarios in the readable Gherkin language, structured for presenting such behaviors:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

Feature: Load and display text from the files and display all headings in blue font color

    Scenario: User loads file successfully
        Given user navigates to the platform 
        And user navigates to the Import File page
        When user selects the file and chooses Import
        Then file is imported successfully 


    Scenario: File is loaded and text displays successfully
        Given user navigates to the platform 
        And user navigates to the Import File page
        When user selects the file and chooses Import
        Then file is imported
        And file text displays in its entirety

    Scenario: File is loaded and text displays successfully and all headings display in blue font color
        Given user navigates to the platform 
        And user navigates to the Import File page
        When user selects the file and chooses Import
        Then file text displays in its entirety 
        And all headings display in blue font color 

Each scenario requires unit testing.

Post-implementation Unit Testing Demo

In the post-implementation approach:

1. Implement the code for all three scenarios.
2. Write tests for these scenarios.
3. Run the tests.

If all scenarios pass, the code is ready. If any fail, we modify and retest the code until all tests are successful.

Test failures are possible since they weren’t developed alongside the features. Any issues, such as headings not displaying in blue, require code adjustments and retesting.

TDD Demo

In TDD, we convert project requirements into tests, feature by feature, before writing any code. Initially, tests fail because the software isn’t implemented yet. However, running them confirms structural integrity: a correct syntax allows the test to run and fail, while a flawed syntax results in a syntax error.

Next, we implement the code and rerun the tests. Each failure prompts code updates and retesting, and a feature is only approved after successful testing.

Using our example, let’s demonstrate TDD. We define and run tests for blue headings. Assuming no syntax errors, we proceed:

1. Write tests for the first scenario.
2. Implement code for the first scenario, iterating until all tests pass.
3. Repeat steps 1 and 2 for remaining scenarios.

This completes the TDD approach.

An Ounce of Prevention

We’ve shown that unit testing provides significant financial savings, bug prevention, and peace of mind.

Benjamin Franklin’s adage, “An ounce of prevention is worth a pound of cure,” remains relevant. Like insurance, unit testing is a valuable investment. The assurance of preventing potential disasters is invaluable.

The Toptal Engineering Blog editorial team thanks Saverio Trioni for reviewing this article’s technical content.