Test business rules and aim for 100% coverage

Where do you keep your business rules? Over the years they turn up everywhere: front-end, back-end, domain objects, a business-rule layer, the database access layer, stored procedures in the database itself. The same rule ends up duplicated, and slightly out of sync, in three or four places at once.

What if there were one source of truth for your business rules, and that source of truth directly drove your tests? You would only ever have one place to look for what a rule actually is, instead of trawling through every layer trying to work out what's really going on.

If you had 100% business-rule test coverage and a green build, you would have huge confidence in the functional correctness of your application — enough confidence to refactor freely, or even rewrite the whole thing in a different language, and trust that it was still correct. When a business rule changes, a business analyst updates the rule and its corresponding tests on a branch, which fails the build, because the tests now describe behaviour the application doesn't have yet. A developer then picks that branch up and makes the build green again by implementing the change.

This works best when business rules are brought into User Story development early, not bolted on afterwards — the same thinking as always test first. Business rules can be tested through Feature Specs using Behaviour Driven Development, drawn out as the story itself is developed, with their availability becoming part of the team's Definition of Ready.

Making it work in practice

• Tests must be able to run individually and independently, so they can run in parallel. Tag every test with a unique ID and the ID of the business rule(s) it covers, so the test runner can select just one test, or every test covering one rule.
• Write the business rules into the feature specs as comments. Each rule can have one or more tests, all tagged with that rule's number.
• Tests must be robust. Flaky tests — often down to poorly handled eventual consistency — undermine the whole point of the exercise.
• Watch your long-running tests. Log how long each test takes, and split up or optimise the slow ones. If every test could start at once, in a perfectly parallel world, your whole suite would only take as long as its single longest test — so a handful of slow tests can dominate your feedback loop.

This doesn't replace unit tests

Absolutely not. Unit tests stay essential: fast, not coupled to a database or external service, not coupled to the implementation, and focused on behaviour — see test functionality, not implementation. Business rule tests sit alongside them as a different, complementary layer: bigger and less iterative than a TDD-style unit test, but sharing the same property of describing desired behaviour rather than implementation detail.

Business rule tests can run long, and parallelising them isn't cheap — but it's still far cheaper than the cost of manual testing at the same scale, and considerably more precise. Done well, this approach also pulls business analysts, testers and developers into the same conversation early, produces better estimates, and means a green build is something the whole team can trust as a genuine release candidate.

This rule is expanded on at much greater length in the original article: Why is Nobody Talking About Business Rule Coverage?