Test Levels: Unit, Integration, System, Acceptance

A booking app isn't tested as one giant blob. It gets tested in layers — the smallest pieces alone, the connections between pieces, the assembled whole, and finally the question "is this what we actually wanted?" The industry calls these layers test levels, and each one catches mistakes the others structurally cannot. Naming the four levels is a standard interview opener; understanding what each can and can't catch is what the answer is really probing.

Think of building a car. You test the brake pads alone on a bench, then the brakes assembled with the wheel, then you drive the finished car around a track, and finally the customer takes a test drive to decide if it's the car they wanted. Four different tests, four different discoveries — and skipping any layer leaves a specific kind of blindness.

Unit Testing: the Smallest Pieces

Unit testing checks the smallest testable pieces of the code — one function, one calculation, one rule — in isolation from everything else. Does the price calculation return 255 when given a 300 booking and a 15% discount? Not the checkout page, not the button — just the arithmetic, called directly, thousands of times a second. Unit tests are written by developers, as code, while they build; a healthy product accumulates thousands of them, and they run in seconds.

Their superpower is precision: when a unit test fails, the broken thing is pinpointed to a few lines. Their blindness is everything outside the unit — a thousand perfect parts can still assemble into a broken machine.

Integration Testing: the Seams

Integration testing checks the places where pieces meet. Does the booking module actually talk to Paylane correctly — right amounts, right currency, right handling when Paylane says no? Do the search module and the availability calendar agree about what "available" means? Seams are where two components, each perfect alone, silently disagree — remember the Mars Climate Orbiter, where two flawless programs disagreed about units and a spacecraft died of the seam.

Integration testing is shared territory: developers write automated integration checks, and testers design scenarios that target the seams — especially the seams with third parties, which Chapter 8 will teach you to probe directly.

System Testing: the Assembled Whole

System testing checks the complete, assembled product through its real interface — the website, the app — the way a traveler would use it. Search for Saltwater Lodge, pick dates, apply SUMMER15, pay with a test card, get the confirmation. This is the level where most of a QA engineer's daily work lives, where the techniques of Chapter 4 get applied, and where the whole-product questions — does this flow work? — finally become answerable.

Its blindness is the mirror of unit testing's: when a system test fails, the cause could be anywhere in the stack, and locating it takes the investigation skills Chapter 8 builds.

Acceptance Testing: the Right Product?

Acceptance testing asks a different question. Not "does it work?" — the levels below covered that — but "is it what we needed?" The business, the customer, or their representatives check the product against its purpose: acceptance criteria met, workflows usable, value delivered. The common form is UAT — user acceptance testing — where actual users or stakeholders run through realistic scenarios before a release. It's deliberately not a re-run of system testing; it's a fitness-for-purpose check, and Principle 7 (bug-free can still fail) explains why it exists as its own level.

Who Tests What

The levels map onto people, and the map answers a question beginners quietly worry about. Developers own unit testing almost everywhere — it happens inside the code, as code. Integration is shared. System testing leans heavily on QA — it's your home level. Acceptance belongs to the business side, often with QA organizing and supporting it. So no, you won't be expected to write unit tests in your first job — but you will be expected to know they exist, because "should this be caught by a unit test or a system test?" is a real conversation, and Chapter 9's test pyramid is built entirely on this ladder.

FW-312 Across the Levels

The date-picker bug makes the ladder concrete. FW-312 — the check-out date that shifts by one day for travelers in certain time zones — could have been caught at three different levels. A unit test on the date-conversion function, fed a time-zone edge case, would have pinpointed the bad math for the cost of milliseconds. An integration test between the date picker and the booking service would have caught the shifted date crossing the seam. In reality, you caught it at system level, testing bookings as a traveler — one level before a real traveler caught it in production. Every level it slipped through made it more expensive; that's the cost curve climbing the ladder, and it's why teams invest in the lower levels even though customers never see them.