Is unit testing worth the effort?

Yes, unit testing is worth the effort for business rules that fail with plausible wrong values, such as date rules. Tests for one rule take about an hour; an escaped bug can cost days of repair. Write one test per branch and boundary, and run the suite in CI on every pull request.

Is unit testing necessary?

Unit testing is necessary for code that computes money or decides who may read a record: test each price rule with its rounding and boundaries, plus one allowed and one denied case per role, in CI on every pull request. Other business rules, such as date rules, are worth unit testing but not required: one test per branch and boundary. Controllers and mappers need no unit tests when endpoint tests in CI assert each field with a distinct value.

How much time do unit tests add?

A Microsoft team of 32 developers spent about 30% more development time in its first year of automated unit tests, and found 20.9% fewer defects in testing (Williams et al., 2009). For one business rule, the tests take about an hour to write, plus ten minutes per change of the rule.

Is unit testing worth it?

Verdict

Yes

Yes, unit testing is worth it for the rules in your code that decide a result, such as status changes, date rules and validation: one test per branch and boundary, run in CI on every pull request.

Why

Blast radiususers
Change frequencyregularly
Detectabilityeventually
Reversibilitywith-effort
Test costmoderate

Yes, unit testing is worth it for the rules in your code that decide a result. The typical case is a customer-facing web application with CI and rules for status changes, dates and validation. Blast radius is users, and Change frequency is regularly, because business rules change about monthly. Detectability is eventually, because a wrong rule returns a plausible value and raises no error. Reversibility is with-effort, since wrong results get saved, and Test cost is moderate, about an hour per rule, so rule R11 gives Test.

When the decision changes
When	Decision	Why
The code computes a price, a discount or an invoice total	Test mandatory: every rule, the rounding and the boundary values	Blast radius rises to money and Reversibility to costly, because a wrong charge ends in refunds
The code decides who may read a record, such as an organisation ID check	Test mandatory: one allowed and one denied case for each role	Blast radius rises to safety-or-legal and Detectability to never, because a leaked record raises no error
The code is a controller or mapper that endpoint tests in CI run with a distinct value in each field	Do not unit test the glue code; rely on the endpoint tests	Detectability moves to immediately and Reversibility to trivial, because a mistake fails an endpoint test before the merge
A service rule changes a few times a year, such as archiving idle projects	Test minimally: one unit test of the main path, plus a regression test for each bug	Change frequency falls to rarely
The code asks a language model to describe a product from its reviews	Test it differently: score an evaluation set before each prompt change and sample live output weekly	Test cost rises to heavy, because the output differs on each run
The code is a one-time backfill of a new column	Test it differently: rehearse the backfill on a copy of production data and keep a backup	Change frequency falls to once, so a test in the suite would never run again

What breaks if you don't test

An untested rule breaks in a later change: a developer adds a case, an old branch stops working, and CI stays green. Customers see wrong statuses, support traces the complaints to the change days later, and every record saved since needs a repair script.

What you lose if you over-test

A unit test of a controller with three collaborators needs three mocks and asserts the calls it makes, so it fails on refactors that change no response. Coverage then marks the controller as covered although no test checks the endpoint response.

How to test

List the branches and boundaries of each rule, such as the last day of a booking window and the day after.
Write one test per branch and boundary that asserts the returned value, with JUnit 5, pytest or another runner.
Replace repositories and the clock with in-memory fakes, so no test touches a database or the network.
Run the suite in CI on every pull request, and add a regression test with each bug fix.

Leave controllers and mappers to endpoint tests, as the practical test pyramid describes.

Procedure and references

When the answer changes

The code charges money or decides who may see a record.
The code has no fixed right answer, such as text from a language model.
Your team requires a unit test for every change: follow the rule.

Real incident + Cost estimate + Code example

Forty minutes of tests against 38 double bookings

On a meeting room booking app I worked on, a change for repeating bookings rewrote the overlap check, and a booking fully inside another stopped counting as a clash. The rule had no unit tests. For 11 days an all-day booking did not block shorter bookings inside it, and 38 pairs of groups turned up at the same room. The repair took about 30 hours: a query to find the pairs, two developers and the office admins moving bookings for a day, and replies to 70 support emails.

The four unit tests we added took 40 minutes to write:

import { expect, it } from "vitest";
import { clashes } from "./bookings"; // clashes(existing, requested)

const at = (from: string, to: string) => ({ from: `2026-03-02T${from}`, to: `2026-03-02T${to}` });
const allDay = at("09:00", "17:00");

it("clashes when the request lies inside a booking", () => {
  expect(clashes(allDay, at("10:00", "11:00"))).toBe(true);
});
it("clashes when the request covers a booking", () => {
  expect(clashes(at("10:00", "11:00"), allDay)).toBe(true);
});
it("clashes when the request overlaps one end", () => {
  expect(clashes(allDay, at("16:30", "18:00"))).toBe(true);
});
it("allows a request that ends when a booking starts", () => {
  expect(clashes(allDay, at("08:00", "09:00"))).toBe(false);
});

The rule changed nine more times that year, and the tests needed two ten-minute edits. At one hour a year against 30 hours for the escaped bug, the tests repay themselves if they stop one such bug in 30 years. They also caught two pull requests that broke a clash case.

Sources

doi.org/10.1109/ISSRE.2009.32

Should I use TDD?Code under test: Yes
Should I write tests before code?Code under test: Yes
Should I unit test everything?No
Do I need unit tests if I have integration tests?No
Should I test the service layer?Yes

FAQ

Is unit testing worth the effort?: Yes, unit testing is worth the effort for business rules that fail with plausible wrong values, such as date rules. Tests for one rule take about an hour; an escaped bug can cost days of repair. Write one test per branch and boundary, and run the suite in CI on every pull request.
Is unit testing necessary?: Unit testing is necessary for code that computes money or decides who may read a record: test each price rule with its rounding and boundaries, plus one allowed and one denied case per role, in CI on every pull request. Other business rules, such as date rules, are worth unit testing but not required: one test per branch and boundary. Controllers and mappers need no unit tests when endpoint tests in CI assert each field with a distinct value.
How much time do unit tests add?: A Microsoft team of 32 developers spent about 30% more development time in its first year of automated unit tests, and found 20.9% fewer defects in testing (Williams et al., 2009). For one business rule, the tests take about an hour to write, plus ten minutes per change of the rule.