Writing Test Cases — Write simple test cases and verify expected outputs

Software testing as a formal discipline traces its roots to the earliest days of computing, when engineers working on room-sized machines discovered that verifying correctness was often harder than writing the programs themselves. Grace Hopper famously documented one of the first literal "bugs" in 1947—a moth trapped in a relay of the Harvard Mark II—but the conceptual challenge of ensuring that code behaves as intended predates even that anecdote. As software systems grew in complexity through the 1960s and 1970s, ad-hoc debugging gave way to more structured approaches: developers began writing small, isolated programs whose sole purpose was to exercise a function and compare its actual output against a known expected result. This practice evolved into what we now call unit testing, and it forms the backbone of modern software quality assurance.

The central question that test-case writing addresses is deceptively simple: how do we know our function does what we think it does? Without a systematic mechanism for comparing actual outputs against expected outputs, developers rely on intuition and manual inspection—approaches that are fragile, non-repeatable, and scale poorly. Writing test cases transforms verification from a subjective judgment into an automated, objective process that can be executed thousands of times without human intervention.

Effective test cases are not random spot-checks; they are carefully designed experiments that probe the behavior of a function under specific, documented conditions. A well-structured test case follows a pattern often called Arrange–Act–Assert (AAA): you set up the preconditions, invoke the function under test, and then compare the actual result with the expected result. Understanding and internalizing the following principles will equip you to write test cases that are both rigorous and maintainable.

The Arrange–Act–Assert pattern provides a uniform structure that makes test cases self-documenting. When a colleague reads your test, the three phases are immediately recognizable, and the intent of the test is apparent from the arrangement of inputs and the chosen assertion. In C++, the assert macro from <cassert> provides the simplest form of the Assert phase: if the condition evaluates to false, the program terminates with a diagnostic message. More sophisticated frameworks like Google Test replace assert with macros such as EXPECT_EQ and ASSERT_TRUE that report failures without aborting the entire test suite, allowing multiple tests to run and report results collectively.

At its most fundamental level, a test case in C++ is simply a function that calls another function and compares the return value (or observable side effects) against a predetermined expected result. The simplest mechanism uses the assert macro from the C standard library, which is available in C++ via the <cassert> header. When you write assert(expression), the compiler inserts a runtime check: if expression evaluates to zero (false), the program writes a diagnostic to stderr and calls abort(). If the expression evaluates to nonzero (true), execution continues silently.

The assert Macro

Anatomy of a Minimal Test Harness

A test harness is the driver code that orchestrates test execution. In the simplest case, a main() function calls a sequence of test functions, each containing its own Arrange–Act–Assert logic. If all assertions pass, the program exits normally (return code 0). If any assertion fails, abort() is called and the remaining tests do not run—which is a limitation that frameworks like Google Test address by catching assertion failures and continuing with subsequent tests.

Test Structure with Google Test

In Google Test, each test case is declared with the TEST(TestSuiteName, TestCaseName) macro, which registers the test function automatically. The framework provides a main() function that discovers all registered tests, runs them in isolation, and prints a summary report. This eliminates the need to manually maintain a test harness and ensures that one test's failure does not prevent subsequent tests from executing.

Writing effective test cases requires thinking beyond the "happy path"—the scenario where everything goes as planned. A robust test suite systematically covers multiple categories of input, each designed to probe a different aspect of the function's behavior. The following classification, rooted in the equivalence partitioning and boundary value analysis techniques from software testing theory, provides a practical framework for deciding which test cases to write.

Notice that even a function with only two integer parameters generates at least six distinct categories of test input. Real-world functions that accept strings, containers, or user-defined types can easily require dozens of carefully chosen test cases. The discipline of boundary value analysis tells us that bugs cluster at the boundaries of input domains—zero, empty strings, maximum integer values, first and last elements of arrays—so these cases deserve disproportionate testing attention.

Consider a function int factorial(int n) that returns n! for non-negative integers and returns −1 for negative inputs as an error indicator. We will write a complete test suite using <cassert>, then show the equivalent using Google Test, walking through each step of the AAA pattern.

C++ offers several mechanisms for writing test cases, ranging from the bare-bones assert macro to full-featured testing frameworks. Each approach occupies a different position on the spectrum of complexity, expressiveness, and automation. Understanding these trade-offs helps you choose the right tool for your project's maturity and scale.

The simple, hand-written test cases covered in this lesson are the foundation upon which more advanced techniques are built. As your software engineering skills mature, you will encounter test-driven development (TDD), property-based testing, fuzz testing, and mutation testing—all of which presuppose a solid understanding of basic test-case construction.

Code coverage tools such as gcov and llvm-cov can quantify what percentage of your source code is exercised by your test suite, providing a measurable metric for coverage completeness. While 100% line coverage does not guarantee the absence of bugs—it says nothing about the correctness of the assertions themselves—it does reveal untested code paths that may harbor latent defects. Integrating coverage analysis into your workflow is a natural next step after mastering manual test-case writing.