Introduction

You have a working C project with a clear structure and implemented features. The next crucial step is ensuring that it actually works — reliably, correctly, and predictably. This lesson focuses on testing your application: why it matters, how to design effective test cases, how to implement unit tests for individual components, how to debug when tests fail, and how to automate testing so you can run checks quickly and consistently.

Why Testing Matters in Your C Projects

As your C programs grow beyond a few hundred lines, relying on “it seems to work” becomes dangerous. Testing helps you:

• Catch bugs early, before they become harder to track down.
• Prevent old bugs from reappearing when you add new features.
• Gain confidence to refactor or optimize code.
• Document expected behavior in an executable form.

When planning your project, you already thought about what needed to be tested. Now you’ll see how to do it systematically.

Designing Effective Test Cases

Good tests are intentional: you choose inputs and expected outputs to exercise specific behavior.

Types of Test Cases

For a function, design at least these categories:

• Typical cases: common, everyday inputs.
• Boundary cases: values at the edges (e.g., 0, 1, max size, empty array).
• Error / invalid input cases: negative values, NULL pointers (if allowed), out-of-range data.

Example: Testing an average Function

Suppose you have a function that computes the average of an array of integers:

#include <stdio.h>

double average(const int *arr, int n) {
    if (arr == NULL || n <= 0) {
        return 0.0;  // defined behavior for invalid input
    }

    long sum = 0;
    for (int i = 0; i < n; i++) {
        sum += arr[i];
    }
    return (double)sum / n;
}

int main(void) {
    int data1[] = {1, 2, 3, 4, 5};          // typical
    int data2[] = {10};                     // boundary: single element
    int *data3 = NULL;                      // invalid

    printf("avg1 = %.2f\n", average(data1, 5));
    printf("avg2 = %.2f\n", average(data2, 1));
    printf("avg3 = %.2f\n", average(data3, 0));

    return 0;
}

// Output:
// avg1 = 3.00
// avg2 = 10.00
// avg3 = 0.00

Explanation:

• We intentionally test a normal array, a single-element array, and a clearly invalid input.
• The function has defined behavior for invalid input (returns 0.0), which makes it testable and predictable.

When you design tests, always be explicit about what should happen for each kind of input.

Implementing Simple Unit Tests in C

Unit testing focuses on testing individual functions or modules in isolation. In C, you can create a separate test program that calls your functions and checks results.

Minimal "Homegrown" Test Harness

You don’t need a full framework to start. A simple pattern is:

• Write helper macros to compare expected vs. actual values.
• Count passed/failed tests.

#include <stdio.h>
#include <string.h>

int max_int(int a, int b) {
    return (a > b) ? a : b;
}

#define ASSERT_INT_EQ(expected, actual, msg) \
    do { \
        if ((expected) != (actual)) { \
            printf("[FAIL] %s: expected %d, got %d\n", msg, (expected), (actual)); \
            failures++; \
        } else { \
            printf("[PASS] %s\n", msg); \
            passes++; \
        } \
    } while (0)

int main(void) {
    int passes = 0, failures = 0;

    ASSERT_INT_EQ(5, max_int(5, 3), "5 vs 3");
    ASSERT_INT_EQ(7, max_int(2, 7), "2 vs 7");
    ASSERT_INT_EQ(-1, max_int(-1, -5), "-1 vs -5");

    printf("\nSummary: %d passed, %d failed\n", passes, failures);
    return (failures == 0) ? 0 : 1;
}

// Output:
// [PASS] 5 vs 3
// [PASS] 2 vs 7
// [PASS] -1 vs -5
//
// Summary: 3 passed, 0 failed

Explanation:

• The ASSERT_INT_EQ macro compares expected and actual values and prints a clear message.
• The program exits with status 0 when all tests pass, which is useful for automation.

Later, you can replace this with a dedicated C testing framework (like Unity, CMocka, etc.), but this pattern is enough to build the habit.

Debugging When Tests Fail

When a test fails, that’s a signal, not a disaster. Use it to drive debugging systematically.

Common Debugging Techniques

1. Reproduce consistently: run the same test repeatedly to confirm it always fails.
2. Narrow the problem: isolate the smallest input that still fails.
3. Inspect with printf (or a debugger): print intermediate values, or step through.

Example: Debugging an Off-by-One Error

Consider a function that finds the maximum value in an array:

#include <stdio.h>
#include <limits.h>

int array_max(const int *arr, int n) {
    if (arr == NULL || n <= 0) return INT_MIN;

    int max = arr[0];
    for (int i = 1; i < n; i++) {
        if (arr[i] > max) {
            max = arr[i];
        }
    }
    return max;
}

int main(void) {
    int data[] = {-3, -10, -1, -7};
    int result = array_max(data, 4);

    printf("max = %d\n", result);
    return 0;
}

// Output:
// max = -1

Explanation:

• This time the output is correct, but if a test revealed a wrong result, you’d:
  • Add extra prints inside the loop (e.g., print i and max each iteration), or
  • Use a debugger (like gdb) to step through and watch max change.

Your tests tell you which input breaks; debugging tools help you see why.

Automating Tests with a Makefile

Running tests by hand becomes tedious as your project grows. You can integrate your tests into the build system so all tests run with a single command.

Assume this structure:

• src/ – your main code
• tests/ – test source files (e.g., test_math.c)
• Makefile – build rules

Example Makefile Snippet for Automation

CC = gcc
CFLAGS = -Wall -Wextra -std=c11

SRC = src/math.c
TESTS = tests/test_math.c

all: app tests

app: $(SRC) src/main.c
	$(CC) $(CFLAGS) -o app src/main.c $(SRC)

tests: $(SRC) $(TESTS)
	$(CC) $(CFLAGS) -o run_tests $(TESTS) $(SRC)

run-tests: tests
	./run_tests

clean:
	rm -f app run_tests

# Output (typical):
# $ make run-tests
# gcc -Wall -Wextra -std=c11 -o run_tests tests/test_math.c src/math.c
# [PASS] ...
# [PASS] ...
# Summary: 5 passed, 0 failed

Explanation:

• make run-tests builds and runs all your unit tests automatically.
• This lets you re-run the full test suite after every change with a single command.

You can extend this to multiple test files, generate coverage reports (with tools like gcov), and integrate into continuous integration (CI) systems later.

Putting It All Together in Your Project

For your current C project:

1. List your modules (files/functions) and define test cases for each.
2. Write small unit test programs that:
   • Include the header for the module.
   • Call functions with carefully chosen inputs.
   • Compare outputs using assertions/macros.
3. Debug failing tests before moving on to new features.
4. Automate by wiring test targets into your Makefile so testing becomes part of your daily workflow.

Over time, you’ll build a safety net of tests that let you confidently modify and extend your code.

Summary / Key Takeaways

In this lesson Testing Your Application, you have learned:

• Importance of Testing: Testing increases reliability, prevents regressions, and lets you change code confidently.
• Test Case Design: Effective tests include typical, boundary, and error scenarios with clearly defined expected behavior.
• Unit Testing Basics: You can build simple unit tests in C using assertion-style macros and separate test programs.
• Debugging via Tests: Failed tests help you locate bugs; you then use systematic debugging (prints or debugger) to find root causes.
• Handling Invalid Inputs: Clearly defining and testing behavior for invalid or edge inputs makes functions more robust.
• Automated Testing: Integrating test compilation and execution into a Makefile allows one-command test runs.
• Test-Driven Workflow: Regularly running your test suite after changes creates a fast feedback loop and supports incremental development.
• Scalable Practice: The same testing patterns you used for small functions will scale to larger modules and full applications.