Regression Tests for Business Rules, Not Just Code

Most people think an automated test proves the software works. It does not, quite. A normal test proves the code runs without crashing and returns something. That catches the loud failures, the blank page and the error screen. It says nothing about whether the software is still obeying the rules your business actually depends on. Those rules can break silently, keep the page loading, and cost you for months before anyone notices.

This is the difference between testing code and testing rules, and it is one of the deliberate habits behind the operating system we built to run Firelinkx. This article walks through what a business-rule test is, why it catches the expensive regressions a human review misses, and what it changes for you as the owner.

A crash is loud. A broken rule is quiet.

When code crashes, you find out fast. A page goes white, a form throws an error, a customer calls to say the site is down. It is annoying, but it announces itself, and someone fixes it that day.

A broken business rule does the opposite. The software keeps running. The page still loads. Orders still submit. Nothing on screen looks wrong. But somewhere underneath, a promise the business relies on has stopped being kept, and it keeps not being kept, order after order, until the day the damage surfaces in a way you cannot ignore. By then it is not a bug report. It is a customer who saw a number they should never have seen, or a batch of records that vanished, or a report you can no longer trust.

What a business rule actually is

A business rule is a promise your software makes that has nothing to do with whether the code compiles. It is something that must always be true, or must never happen, for the business to be safe. Here are the kinds of rule we write tests for.

A sensitive calculation must never leave the building

Some logic is supposed to run on our server and never be sent to the customer's browser. Our pricing engine is the clearest example: the way a quote is calculated is a trade secret, and only the final number should ever reach the visitor, never the formula behind it. The code can run perfectly and still leak that formula if someone, months later, moves one file to the wrong side of the line while adding an unrelated feature. Nothing crashes. The site works. The secret is just on public display now.

So we write a test whose only job is to stand at that boundary and check. If the pricing logic ever ends up in the code that ships to the browser, the test fails, the build stops, and the change never reaches the public. The rule is not "remember to keep pricing on the server." The rule is enforced by a machine that never forgets and never gets busy. We wrote about the principle itself in why we don't let AI quote prices, and this is how we keep that promise mechanically true.

An archived record must stay archived

Say your system lets staff archive an old customer or cancel a job. The rule is simple in English: once it is archived, it stays gone from the active list and cannot be brought back to life by a later action. Now imagine a developer adds a new feature that touches the same records, an import tool, a bulk-update button, a report. If they are not careful, that new feature can resurrect an archived record as a side effect, and it will happen without any error at all. Suddenly a customer you deliberately removed is back in your active list, or a cancelled order is being fulfilled.

A rule test locks this down. It archives a record, runs the new feature, and checks that the record is still archived afterward. If the change would have resurrected it, the test fails before the feature ever ships. The same discipline is why we care so much about the order operations run in, which we cover in ordering side effects in checkout and booking.

A data change must not orphan records

Software grows, and growing means changing the shape of your data. You add a field, split a table, rename a category. Each of those changes is a moment where records can be silently stranded: an invoice that no longer points at a customer, a job with no client attached, a payment linked to an order that no longer exists. The application does not crash over an orphaned record. It just shows you a slightly wrong total, or a list with a hole in it, and you may not spot the hole for a year.

We write tests that make the data changes on a copy and then check that nothing was orphaned: every invoice still has its customer, every job still has its client. If a proposed change would strand records, the test fails and we fix the migration before it ever runs against your real data. This is one of the invisible reasons custom software can be trusted with the numbers you run the business on.

A required safeguard must stay wired in

Some protections are only useful if they are always on. The rules that welcome the AI crawlers that recommend you, the security headers that protect your visitors, the settings that keep your pages findable on Google: each of these is one deleted line away from being switched off by accident, and switching them off produces no error message. The site looks fine. It is just invisible to AI now, or less secure, or dropping out of search.

So we test that the safeguards are present. A test checks that the named AI crawlers are still explicitly allowed, the way we describe in getting recommended by AI search. Another checks that the key security and discovery settings are still in place. If a future change would remove one, the build fails and asks whether that was really intended. Nobody has to remember the list. The list defends itself.

Why a human review cannot catch these

It is fair to ask why you cannot just have a careful person check. The answer is that these regressions are invisible exactly where a human is weakest. A code review looks at the change in front of it. The broken rule is usually somewhere else, a side effect three files away that the reviewer had no reason to open. The change looks correct in isolation, and it is, until you consider a promise made in a different part of the system months earlier.

People also get tired, get rushed, and forget. The developer who wrote the pricing boundary may have left. The person reviewing the change may not know the rule exists. A rule test does not depend on any of that. It was written once, by the person who understood the rule, and it now runs automatically on every single change, forever, without ever having a bad day. That is the whole point: the knowledge is captured in something that cannot forget it.

What this changes for you as the owner

You will never read these tests, and you should not have to. What you get is a different kind of confidence in your software as it grows. Most systems get riskier with every change, because every change is a new chance to break something old. Rule tests invert that. The more rules you protect, the harder it becomes to break them by accident, so the software gets safer to change over time, not more fragile.

• The promises your business depends on are enforced by machines, not by hoping every developer remembers them.
• A change can add a feature without silently damaging something that was working, because the old rules are still being checked.
• When something is about to break, it breaks the build on our side, before it ships, instead of breaking your business in production.
• The system stays safe to improve for years, so you are not stuck choosing between an evolving product and a stable one.

This is a large part of why a well-built custom system is worth more than the sum of its features. The features are what you see. The rules that guard them, on every change, are what let you rely on it. It is also one of the practical answers to why so many software projects fail: not because the first version was wrong, but because nothing protected it as it grew.