MC/DC Testing in Zig: Reliability Lessons From SQLite - Richard Hipp | SSW 2026

shwaa · August 4, 2026, 5:25am

This talk was a fascinating watch. Richard Hipp uses the story of SQLite’s development to exemplify the benefits of rigorous software testing. One of the methods that intrigued me was coverage testing on code conditions (“Modified Condition/Decision Coverage”), since it forces verification and justification of each decision your program makes. It can be automated using tools like kcov and gcovr. I also found this github issue about it, and it seems like kcov works well due to being compiler-agnostic.

As a relatively new Zig programmer and test author, I wondered how MC/DC coverage testing is used in-practice for Zig projects, and when it makes sense to enforce this level of scrutiny.

Some discussion questions:

Have you applied MC/DC in your Zig codebase, if so how?
If you have exercised MC/DC testing in general, what is your experience?
How might comptime conditions and lazy compilation be treated when MC/DC testing?

glfmn · August 4, 2026, 2:38pm

Some of the challenges Richard mentioned with mocking the interface to the OS are a bit easier/different in zig thanks to std.mem.Allocator and std.Io. We have testing versions of both that can (or will in the future) catch errors related to misuse.

It makes it easier to build simulators and stuff. Here’s a fun example from the standard library:

std.testing.checkAllAllocationFailures

I think more extensive Io testing facilities are on the roadmap? But someone deeper in the guts or more up to date with development can confirm.

The team behind Tigerbeetle, also a database, have produced some interesting talks and blog posts about testing practices. This isn’t MC/DC, but they have a simulator which injects faults:

github.com/tigerbeetle/tigerbeetle

src/vopr.zig

37b33a2a9

const std = @import("std");
const stdx = @import("./stdx.zig");
const builtin = @import("builtin");
const assert = std.debug.assert;
const maybe = stdx.maybe;
const mem = std.mem;
const ratio = stdx.PRNG.ratio;
const Ratio = stdx.PRNG.Ratio;

const constants = @import("constants.zig");
const flags = @import("./flags.zig");
const schema = @import("lsm/schema.zig");
const vsr = @import("vsr.zig");
const fuzz = @import("./testing/fuzz.zig");
const Header = vsr.Header;

const vsr_vopr_options = @import("vsr_vopr_options");
const state_machine = vsr_vopr_options.state_machine;
const StateMachineType = switch (state_machine) {
    .accounting => @import("state_machine.zig").StateMachineType,

This file has been truncated. show original

The zig toolchain comes with fuzz testing as well. Fuzzing can help find unexpected failures (as mentioned in the talk) but isn’t as deterministic as 100% test coverage would be. It’s great to use fuzzing in combination with checkAllAllocationFailures!

Looking to the future, something like checkAllAllocationFailures but maybe for checkAllCancellations or checkAllIoFailures would help exercise error paths and improve test coverage.

Recently, I’ve started trying to use testing.expectError more when I can, both to exercise the error paths and document expectations.