# Testing

URL: https://tuios.dev/blog/topic/testing

> Fuzzers, end-to-end tests, and tests that could not fail.

## Posts

- [The daemon sent a client an older state after a newer one](https://tuios.dev/blog/the-daemon-sent-an-older-state-last.md): A flaky tuios test turned out to be the daemon delivering session state out of order. The first fix ordered by the state Version, and the review found the one kind of change that never moves the Version. The second fix counts every change.
- [One fuzz failure was the test, one was the emulator](https://tuios.dev/blog/one-fuzz-failure-was-the-test.md): Two fuzz targets failed in tuios on the same evening. The kitty graphics target had an oracle that an allocator change left behind, and my first fix made it too lenient. FuzzModel found a real bug, a cut-off UTF-8 rune that ate the escape after it.
- [Three flaky tests, and what they were hiding](https://tuios.dev/blog/three-flaky-tests-and-what-they-were-hiding.md): Nine tests failed now and then on CI in the last days of September. Two were product bugs, and the work turned up a third. A hook that waited on itself, a broken pipe that should have been an error, and a command line the shell echoed twice.
- [A window named db](https://tuios.dev/blog/a-window-named-db.md): An end-to-end test lost an agent's state about twice in a hundred runs. It was not a race. The pane was named db, db is hex, and -w tried a window id prefix before an exact name.
- [Tests that could not fail](https://tuios.dev/blog/tests-that-could-not-fail.md): A resize fuzzer whose only screen check sat behind a constant false, a palette test that measured the length of a fixed-size array, and a pinned repro that lost one byte to encoding/json. All three were green, and none of them could go red.
- [Deleting two thirds of the unit tests, then putting a third back](https://tuios.dev/blog/deleting-two-thirds-of-the-unit-tests.md): In one day I cut the tuios unit tests from 4,239 to 1,470 under a strict rule, then restored 1,395 of them. The rule asked what kind of test it was. The review asked whether a bug gets past the E2E suite without it.
- [Nothing failed, so nothing was fixed](https://tuios.dev/blog/nothing-failed-so-nothing-was-fixed.md): A whole-codebase audit of tuios found a flag nothing set, an interface with one implementation behind 140 call sites, and copies of code that had quietly drifted apart. Dead code survives because nothing fails when it is wrong.
- [The fuzzer that found nothing, and the two questions that found everything](https://tuios.dev/blog/the-fuzzer-that-found-nothing.md): 590,000 fuzz runs against the tuios terminal emulator found nothing, because they checked that the screen was well formed, not that it was right. Two properties that compare the emulator with itself found two real bugs.
- [My differential tests passed and the screen was pink](https://tuios.dev/blog/my-differential-tests-passed-and-the-screen-was-pink.md): A style cache keyed by recycled libghostty-vt style IDs painted ls output hot pink, and a differential test suite that compared once, at the end, missed it.
- [The daemon said yes to an option that did not exist](https://tuios.dev/blog/the-daemon-said-yes-to-an-option-that-did-not-exist.md): Driving the tuios control socket the way a program would found a command that lost its spaces, a parameter that was silently dropped, and 88 settings of which six applied live.
- [My fuzzer was optimising for my own bug](https://tuios.dev/blog/fuzzing-a-terminal-test-harness.md): A flaky TUI fuzz suite came down to a PTY line discipline I never configured, and a shrinker that minimised straight toward the race.