sven's blog

Encoding mutations directly into the test code

Wed, 13 May 2026 06:59:00 +0200

I sometimes annotate a test case with the (potential) mistake that caused me to introduce the test in the first place, as it can make it easier to understand why a test looks the way that it does.

Consider the following module, written in F#:

open System

module Validator =
    let isAllowed (now: DateTime) (date: DateTime) = now.Date <= date

I might, for example, write the following comment inside of one of its test cases:

Testing complex high-level functions

Sun, 22 Mar 2026 09:09:00 +0100

In You probably shouldn’t test the leafs directly, except when…, I snuck in a pesky “reasonably” somewhere mid-sentence:

If you can reasonably test the entire tree by testing the root, then do it.

What do you do if you can’t reasonably test the entire tree by testing the root? Well, you write tests against some of your lower-level functions.

We can’t really stop there, though. You still need to the test the high-level functions somehow. How do you prevent the tests for your high-level function from becoming unbelievably complex?

Writing the steps to validate a test that already passes in the commit message

Fri, 20 Feb 2026 06:31:44 +0100

I previously argued that there is value in verifying that a commit that purports to add a failing test actually adds a failing test, and that we might want to encode that information in the commit message somehow.

What if, however, you want to insist on making what has sometimes been called “The Perfect Commit”, which adds both the production code and the passing test at the same time?

Or what if you’re simply writing a Characterization Test for existing code, and are following some variation of the following recipe?

Should we start writing verifiable claims in commit messages?

Thu, 19 Feb 2026 19:28:08 +0100

Whether or not every commit should build and pass all of its tests is, arguably, a contentious issue:

Every commit should be runnable, that is we should be able to git checkout any commit and get a functional code base. This means no “WIP” commits or commit chains that only restore functionality at the end.

— Cleaning Up Git History, Robin Schroer

Within a feature branch, not every commit necessary passes the tests (or even builds), and that is a useful property! Here’s some ways this can be exploited:

You probably shouldn't test the leafs directly, except when...

Thu, 14 Aug 2025 10:28:58 +0200

Focus on unit tests, but relax the definition of what a “unit” is.

It shouldn’t be language constructs (such as classes or methods) that dictate how much a unit test is allowed to cover, but rather the complexity of the code that you’re testing. You can often achieve the exact same test coverage and the exact same mutation resistance by testing your program at a slightly higher level, and you will get a lot to show for it.