# Wrote tests for the checkers themselves after establishing that a checker fed only clean input will one day report clean because it read nothing — planting a misspelling to confirm the spell‑check finds it, and taking an id range from the database rather than from a number in the test. 2025 **Situation.** The project runs a set of custom checkers over its own content — a spell check, an identifier‑range check, a voice check, a figure‑consistency check. Each of them had run green for months. A checker that has only ever seen clean input and only ever reported clean is indistinguishable from a checker that reads nothing at all, and there was no test in the suite that could tell the two apart. **Task.** The checkers had to be made to prove they can fail, and the fixtures they check against had to stop being hand‑maintained copies of the thing they describe. **Action.** The pattern applied throughout is to plant the defect the checker exists to find and require the checker to find it. The spell check is fed a deliberately misspelled word and the test fails if the run comes back clean. The voice check is fed prose in the first person and must reject it. The buzzword check is fed a banned word. Each of these is a small test and each one closed a real blind spot, because two of the checkers turned out to be reading a narrower set of files than their documentation claimed and had been silently skipping content. The second change is about where a test gets its expectations: the identifier‑range check previously compared against a number written in the test file, which meant every content addition required editing a test, and an editor who updated the number without looking had disabled the check. It now derives the range from the database, so the check describes the data rather than a stale memory of it. **Result.** Every checker in the project now has a test that proves it fails on bad input, and the range assertions read from the source of truth. The uncomfortable part is what this exposed: a green check had been meaningless in at least two places for an unknown length of time, and there is no way to find out retroactively what passed through. --- - Role: Test and Quality Engineer - Categories: [Databases](https://engineer.company/categories/databases/), [Data Governance](https://engineer.company/categories/data-governance/), [Automation & CI/CD](https://engineer.company/categories/automation/), [Testing & QA](https://engineer.company/categories/testing/), [Python](https://engineer.company/categories/python/) - Services: [Data Governance & Quality](https://engineer.company/services/data-governance/), [DevOps & CI/CD Automation](https://engineer.company/services/devops-cicd/), [Technical Leadership & Consulting](https://engineer.company/services/technical-leadership/)