Test With An F

How Test With An F Actually Works

The core idea behind Test With An F is straightforward but people keep making it into something mystical. You write a test before the code exists. That test fails. Then you write the minimum code to make it pass. Then you refactor. The F stands for Fail, and the whole process depends on actually letting that test fail instead of skipping past it or masking the failure with sloppy setup code. Pick a small piece of functionality you need to build. Not a whole feature, not even a medium-sized one. Something you can describe in one sentence. For example: "given an empty list, sort should return an empty list." That's your starting point. Write the test for exactly that case and nothing else. Do not add edge cases yet. Do not add helper functions. Just write the test, watch it fail, then write the absolute minimum code that makes it pass. I remember working on a payment reconciliation tool a few years ago where I was supposed to build a function that matched incoming transactions against a ledger. The team had been trying to write comprehensive tests from the start and they'd spent three days writing setup code that never actually ran because of a dependency ordering issue. I sat down, wrote one test for exact-match transactions using Test With An F, saw it fail, wrote a single loop with an equals comparison, watched it pass, and then moved to the next case. The whole matching engine ended up taking about two hours from zero to working code, and it was correct because every single edge case had a failing test driving it forward individually.

The cycle you actually follow

Each iteration of Test With An F has three phases. First, write a test that fails. This is the red phase. The test needs to be descriptive enough that when it fails you know exactly which case you're covering. Second, make it pass with the least amount of code you can manage. This is the green phase. Resist the urge to add error handling, logging, or defensive programming here. Your only goal is to get the test to pass. Third, look at what you wrote and ask if it's ugly. If it is, refactor it while keeping all tests passing. This is the refactor phase. Never refactor without the tests running first. The most common mistake people make at this stage is adding too much in the green phase. They see a failing test and immediately write production-quality code with null checks, type coercion, and boundary handling all at once. That defeats the purpose of having the test guide you. Write the simplest possible thing that passes, then let subsequent failing tests force you to expand the logic.

When Test With An F breaks down

There are situations where this approach hits a wall. The biggest one is code that depends heavily on external state, like a live database or a third-party API. If you try to write a test for something that queries a production database before your local environment is fully set up, you'll spend more time configuring mocks than you would have spent writing the code directly. I ran into this building an export module that pulled from two separate services. The test kept failing because of race conditions in the mock responses, and I ended up spending an afternoon debugging the test infrastructure instead of the actual export logic. What I did instead was use Test With An F for the data transformation part, which was pure logic with no external dependencies, and then wrote integration tests separately for the parts that needed live connections. That split approach saved me from either giving up on testing or turning every test into a fragile mock. Another hard limit is exploratory work. If you're doing research or prototyping and you genuinely don't know what the code should do yet, writing tests first is a waste of time. You can't fail what you haven't defined. In those cases, write the code quickly, understand the behavior, then go back and add tests. Test With An F is a design tool, not a replacement for figuring out what you're building.

Practical tips from doing this repeatedly

Keep tests focused on behavior, not implementation. If you're testing a function that returns a sorted array, assert the output is sorted. Don't assert that it used a particular algorithm or hit a specific number of comparisons. When you structure tests around what the code does rather than how it does it, the refactor phase becomes genuinely useful because you can change the implementation freely without breaking tests. Run your test suite after every single change, even tiny ones. This sounds obvious but it's where most people slip away from the method. I've seen teams switch to Test With An F and then only run tests at the end of the day. That turns the approach into just another way to write tests after the fact, which loses all the benefits of the fail-first design feedback loop. Even if you're on a slow machine, run the tests. The habit matters more than the speed. If a test feels hard to write, that's usually a signal that the function you're trying to build is doing too much. Break it into smaller pieces until each piece has a test you can actually write in under a minute. This is one of the counter-intuitive things about Test With An F that beginners miss. The difficulty of writing the test is diagnostic information about your code design, not just a personal obstacle to push through. A function that takes eight arguments and touches four different objects is almost certainly not testable in the way this method requires, and the fix is to decompose it before you try harder.

The approach works best when you treat the failing test as a real failure and not something to work around. Sometimes you'll hit a case where the test fails for an unexpected reason and your instinct is to adjust the test to match the current code instead of adjusting the code to match the test. That instinct is wrong. The test represents what you agreed the code should do. If the code doesn't match, the code is wrong. Move the code, not the test.