Why We Write Unit Tests

For many new developers, the concept of “unit testing” can seem like an extra, perhaps even optional, step in the process of building software. The primary goal, after all, is to write code that works. However, the mark of a professional software engineer lies not just in creating functional code, but in building reliable, maintainable, and high-quality software. Unit testing is a foundational practice that underpins all of these goals. It is not a chore to be completed after the “real” work is done; it is an integral part of the development process itself.  

This lesson will guide you through the powerful new Swift Testing framework introduced at WWDC 2024. This lesson will cover the following learning objectives.

• Articulate the importance of unit testing for improving code quality, preventing regressions, and enabling confident refactoring.  

• Implement tests using the @Test macro and validate behavior with the #expect and #require macros to check for correct outcomes and necessary preconditions.  

• Organize tests into a clear hierarchy using @Suite types and apply semantic Tags to categorize and filter tests across the entire suite.

• Customize test behavior by applying traits to implement parameterized tests, set time limits, and conditionally enable or disable tests based on runtime conditions.

Building Confidence and Ensuring Accuracy

At its core, unit testing is the practice of verifying the smallest, most isolated pieces of your application’s code—the “units”. A unit is typically a single function or a method within a class or struct. The goal is to confirm that each unit performs its specific task correctly, according to the developer’s logic, before it is integrated into the larger system.

The Economics of Bug-Fixing: Early Detection is Key

One of the most compelling arguments for unit testing is economic. The cost of fixing a software bug is not constant; it grows exponentially the later it is discovered in the development lifecycle. A bug caught by a developer moments after it’s written can be fixed in minutes. A bug found during integration testing might take hours to trace and resolve. A bug discovered by a user in the live, production version of your app can be catastrophic, requiring emergency patches, potentially damaging your reputation, and costing significant time and resources to fix.  

The Safety Net for Change: Fearless Refactoring and Regression Prevention

Software is rarely static. Over time, you will need to add new features, optimize performance, or improve the internal structure of your code. This process of improving the design of existing code without changing its external behavior is called “refactoring”. Refactoring is essential for maintaining a healthy and scalable codebase, but it can be a source of anxiety. How can you be sure that your improvements in one area haven’t accidentally broken something else?

Tests as Living Documentation

Finally, well-written unit tests serve as a form of living, executable documentation. A new developer joining your team might struggle to understand a complex function by reading its implementation alone. However, by looking at its unit tests, they can quickly grasp its purpose and intended behavior.  

• Each test case clearly demonstrates a specific scenario:
• Given a certain set of inputs…
• When this function is called…
• Then this is the expected output or behavior.

This format provides clear, unambiguous examples of how the code is meant to be used. Unlike traditional documentation, which can become outdated, unit tests are always in sync with the code. If a test fails, it means either the code is broken or the test (the documentation) is wrong. In either case, the discrepancy must be resolved, ensuring the documentation remains accurate over time.