In a recent discussion with one of my mentors in full-stack web development, I was explaining how I learned certain frameworks and libraries. After seeing my approach, he remarked, “This looks like… Test-Driven Education.”

I consider myself a Test-Driven Development (TDD)-oriented software engineer. Little did I know that TDD not only helps me write new code but also deepens my understanding of existing or third-party code, whether in a library or not.

One thing I honestly dislike is reading documentation. It’s just so hard for me - I get sleepy and lose focus. On the other hand, I love breaking things. As a kid, I enjoyed throwing objects from high places just to watch them smash. The good news in software is that things never truly break; at worst, tests turn red.

On a more practical level, documentation can be outdated, mismatched with the software version I’m using, or even incorrect. Given that the ultimate source of truth is the code itself, I prefer working directly with it.

I start with a minimal test and a minimal implementation (which may involve third-party or legacy code), as is standard in TDD. But before moving forward, I break the tests. And here’s where things get interesting - how do you break tests? In general, I’ve found three ways:

  • Break the test input
  • Break the test output
  • Break the code

Let’s go through an example to illustrate this process.

function oddOrEven(x: number): string {
    if (x % 2 === 1) {
        return 'odd';
    }
    return 'even';
}

describe('oddOrEven() tests', () => {
    it('should be odd', () => {
        const result = oddOrEven(3);
        expect(result).toEqual('odd');
    });

    it('should be even', () => {
        const result = oddOrEven(6);
        expect(result).toEqual('even');
    });
});

Breaking the Test Output

This is the simplest approach - just change the expected result to something incorrect:

it('should be odd', () => {
    const result = oddOrEven(3);
    expect(result).toEqual('even'); // broken
});

Why do this? The reason is simple: to ensure that the test actually runs. I don’t trust a test unless I’ve seen it fail. Watching tests fail is valuable - it proves that they are executing and that my assertions are correct. In other words:

  • The test should pass when the expected output matches the actual output.
  • The test should fail when they do not match.

The second point is arguably even more important. A test exists to fail when something is wrong. That’s why I always like to see tests fail first.

Breaking the Test Input

This method is even more straightforward:

it('should be odd', () => {
    const result = oddOrEven(4); // broken
    expect(result).toEqual('odd');
});

If changing the input doesn’t affect the test result, it means something is wrong - either with the test or the code. Is the input actually being used? Does execution even reach the part where the input matters?

This becomes especially important when testing functions with multiple parameters. Consider:

function foo(param1: string | null, param2: number): number {
    if (param1 === null) {
        return 0;
    }
    return bar(param1, param2);
}

There’s no reason to test foo() with different values of param2 when param1 is null. If a test does that, and changing param2 has no impact, it’s a strong signal that something is missing. In this case, the real behavior to explore is inside bar().

A better approach would be to:

  1. Test foo() with param1 as null.
  2. Test foo() with param1 as string.
  3. Test bar() directly for its behavior with different param1 and param2 values.

Breaking the Code

This is my favorite part - finding ways to break the tests by modifying the code itself. We have two tests; how can we break both?

function oddOrEven(x: number): string {
    if (x % 2 !== 1) { // broken: !== instead of ===
        return 'odd';
    }
    return 'even';
}

Someone might argue that, since both tests fail, one test is enough. In simple cases, this might seem obvious. But with more complex or unfamiliar code, it’s not always so clear.

To challenge the “one test is enough” notion, we can break the code in ways that cause only one test to fail:

function oddOrEven(x: number): string {
    if (x % 2 === 1) {
        return 'even'; // broken: 'even' instead of 'odd'
    }
    return 'even';
}

Or:

function oddOrEven(x: number): string {
    if (x % 2 === 1) {
        return 'odd';
    }
    return 'odd'; // broken: 'odd' instead of 'even'
}

Another way to break both tests:

function oddOrEven(x: number): string {
    return 'notOddNotEven'; // broken
    if (x % 2 !== 1) {
        return 'odd';
    }
    return 'even';
}

This approach is more subtle. My point is that breaking the code in multiple places and ways sheds light on its behavior under test. If breaking the code doesn’t lead to test failures, that’s an immediate red flag - there’s insufficient test coverage. The tests must be revised before continuing development.

Often, this process leads to better tests. Sometimes, it even forces a completely different architecture when I realize my initial approach doesn’t work at all - whether in terms of implementation, test structure, or even fundamental design choices.

Regardless, each failure provides valuable insight. I learn more about how the code behaves.

Tests Test the Code, Code Tests the Tests

We say that tests validate the code. But tests are also written in code - usually in the same language as the application. So where do we draw the line between “test code” and “application code”? Without the test framework (e.g., Jest), both are just code!

Some might argue that “application code” runs in production, while “test code” does not. But we execute tests on that application code, often in CI/CD pipelines. We also perform integration, exploratory, canary, and smoke tests in real environments.

Ultimately, can we say that tests validate the code, and the code validates the tests? In my experience, yes. Breaking both parts of this loop - tests and implementation - deepens my understanding of their behavior. By doing so, I improve both the tests and the code they verify.