We're about to cross a milestone the whole team is proud of: 10,000 automated tests running against the NomNom server. Not ten thousand lines of code — ten thousand individual, independent checks, each one asking a single question about how the system behaves and refusing to let the answer change without us noticing.
We want to talk about why that number exists, because it says something about how we build NomNom — and what that means whether you run a restaurant or build software for a living.
What a test actually is (the 30-second version)
If you don't write software, here's the idea. Every time we add a feature — a new way to take a deposit, a change to how availability is calculated, a tweak to a confirmation email — we also write small programs whose only job is to check that the feature does exactly what it should, including all the awkward edge cases. What happens when two guests try to grab the last table at the same instant? What happens when a card payment succeeds but the customer closes their browser before the page reloads? What happens at a daylight-savings boundary?
Each of those questions becomes a test. And here's the important part: those tests don't run once and get thrown away. They run every single time we change anything, forever. Ten thousand of them, in under a minute, before a single line reaches you.
Every feature is tested before it hits the App Store
This isn't a nice-to-have we get around to when there's time. On NomNom it's a hard rule: no change is considered finished until it has tests covering it. New booking logic, a pricing change, a security fix — if it doesn't come with tests, it doesn't ship.
That's deliberately inconvenient. It slows us down in the moment. But it's the single biggest reason we can move quickly over time without breaking the things you already rely on. When you've got a Saturday night fully booked, the last thing you need is for last week's “small improvement” to have quietly broken this week's confirmation emails. Those ten thousand tests are the safety net that catches exactly that — automatically, every time, before any of it touches a real restaurant.
Where we're strictest
Tests aren't spread evenly, and they shouldn't be. We pour the most into the parts of the system where a mistake would actually hurt you:
- Money. Deposits, refunds, voucher purchases, and every twist of the card-payment flow are covered by hundreds of dedicated tests on their own. We test what happens when a payment confirmation arrives twice, arrives late, or races against the customer's own browser — because real-world payments are messy, and “we charged someone twice” is never acceptable.
- Your data staying yours. NomNom runs many restaurants on shared infrastructure, and a whole family of tests does nothing but verify that one venue can never see or touch another's bookings, customers, or settings. This is one of the most heavily guarded parts of the entire codebase.
- The booking engine. Availability, table allocation, closures, special dates, custom service times, capacity limits — the genuinely hard logic at the heart of the product — is checked from every angle, including the unusual exceptions that real restaurants actually need.
- Everything that talks to your guests. Confirmation emails, reminders, SMS messages — tested so the right message goes to the right person, once.
And when we do find a bug — because every real system has them — we don't just fix it. We write a test that reproduces it first, watch that test fail, then make it pass. From that moment on, that exact bug is locked out permanently. It can never quietly come back in a future update.
For the developers reading this
If you build software for a living, you'll know that a test count on its own is a vanity metric. So here's what's actually behind ours.
It's a Delphi / Object Pascal backend on DMVCFramework, with a DUnitX suite of nearly 10,000 tests across more than 240 test files. The things we care about more than the headline number:
- Not a single test touches the live database. The whole suite runs against fake, in-memory service implementations — so it's fast, deterministic, runs anywhere, and there is zero chance of a test run corrupting real data. Business logic is deliberately extracted into pure, side-effect-free units precisely so it can be tested honestly rather than mocked into meaninglessness.
- The test-per-change rule is enforced, not aspirational. It's written into how we work, and we hold ourselves to it on every commit.
- Tests pin real incidents. A good chunk of the suite exists because something once went wrong in a subtle way — a serialization edge case, a memory-ownership bug, a multi-tenant leak — and we refused to let it recur. Those tests are institutional memory you can run in 60 seconds.
- Security and memory safety are first-class. Cross-tenant isolation, injection and XSS handling, and memory-leak safety each have their own dedicated suites, not a few tests bolted onto something else. (You'll spot Tests Leaked: 0 in the screenshot above — the suite checks for memory leaks too.)
This is what a small, serious team looks like when it's been doing this for a long time. We don't have a separate QA department to hide behind. We have discipline, and we have ten thousand tests that never get tired, never skip a check, and never assume “it probably still works.”
Why we're telling you this
Because most of this work is completely invisible. You'll never see a test pass. You'll just notice that NomNom keeps getting better, and that the things you depend on keep working while it does. That's not luck. That's ten thousand quiet checks standing between every new idea and your restaurant.
We're not slowing down — we're shipping new features constantly. You can see everything we've shipped so far — and what's coming in the next release on our version history page. The tests are how we get to do both: move fast and let you trust that the thing you ran your business on yesterday will still run it tomorrow.
Here's to the next ten thousand.