Theory
Does it actually work?
You have built the system. But does it actually work, correctly, reliably, and as the users need? Finding out is the job of testing, and doing it properly is what separates a project that impresses from one that falls apart in the demo.
Testing happens at three levels, from the smallest pieces up to the whole system with its users: unit testing, integration testing, and user acceptance testing. Each catches a different kind of problem. This closing lesson of the development unit explains them, so you verify your project thoroughly and find the bugs before your evaluators (or users) do.
At a glance
| Level | Tests what | Question it answers |
|---|---|---|
| Unit testing | The smallest pieces (functions, methods, components) in isolation | Does each individual part work correctly? |
| Integration testing | Connected parts working together (front end + back end, back end + database) | Do the parts work together? |
| User acceptance testing (UAT) | The whole system against users' real needs | Does it do what the user actually wanted? |
Theory
From small pieces to the whole system
The levels build up from small to large.
Unit testing checks the smallest pieces, individual functions, methods, or components, in isolation: does each one do its job correctly? It catches bugs at the source, in a single piece.
Integration testing checks that connected parts work together: the front end with the back end, the back end with the database, modules interacting. As the last lesson warned, this is where connection problems (mismatched formats, auth) surface, so this level catches them.
User acceptance testing (UAT) checks the whole system against the users' real needs, does it actually do what the user wanted, per the requirements? It is often done with or by real users or stakeholders. UAT is the final judge: not just 'does it work?' but 'does it work for the people it is for?'.
Quiz
Testing that individual functions or components each work correctly in isolation is which level of testing?
- User acceptance testing, because it involves users
- Unit testing, which checks the smallest pieces (functions, methods, components) individually
- Integration testing, because it connects parts
- It is not testing at all
Show the answer
Unit testing, which checks the smallest pieces (functions, methods, components) individually
Testing individual functions or components in isolation, to check each one works correctly on its own, is unit testing, which targets the smallest pieces of the system. Option A, user acceptance testing, checks the WHOLE system against users' real needs, not individual functions. Option C, integration testing, checks that CONNECTED parts work together, not pieces in isolation. Option D is wrong: unit testing is a fundamental level of testing. The levels build up: unit (individual pieces), integration (parts working together), then user acceptance (the whole system meeting user needs).
Think first
Why test at multiple levels instead of just checking the whole system works at the end?
Why bother with unit and integration testing when user acceptance testing checks the whole thing? Then tap.
Show the answer
Because testing only the whole system at the end tells you SOMETHING is broken but not WHERE, and lets bugs hide until they are expensive to find, whereas testing at multiple levels catches problems close to their source, early, and makes them far easier and cheaper to fix. Each level answers a different question and localises problems differently. UNIT testing checks each small piece alone, so if a function is wrong, you find out immediately and know EXACTLY which function to fix, no hunting through a huge system. It also lets you build on pieces you KNOW work. INTEGRATION testing then checks that the connected parts cooperate, catching the mismatched-assumption problems that only appear where parts meet (as the integration lesson explained); if it fails, you know the problem is in a specific connection, not somewhere in the whole application. USER ACCEPTANCE testing finally checks that the complete system actually meets the users' real needs, a different question again ('is it right for the user?', not just 'does it run?'). If you SKIPPED unit and integration testing and only ran the whole system at the end, then when something failed you would face the hardest possible debugging task: a bug somewhere in a large, interconnected system, with no clue whether it is a single function, a bad connection, or a misunderstanding of requirements, and with many components able to hide or mask each other's faults. Worse, you would discover the pile of bugs late, when there is little time to fix them, exactly the crisis that sinks projects. Multi-level testing is like inspecting each brick, then each wall, then the whole house: problems are caught at the smallest scope where they are cheapest to fix, and by the time you test the whole system, most faults are already gone, so UAT can focus on whether it truly serves the users. This layered approach also builds confidence steadily and fits incremental development. So testing at multiple levels is not redundant; each level catches what the others cannot, and together they find bugs early and pinpoint them, which is why professional software is tested this way, and why your project should be too. Test small, then connected, then whole, and problems have nowhere to hide.
Summary
Key takeaways
- Testing verifies your project works and meets requirements, at three levels from small to whole-system.
- Unit testing checks the smallest pieces (functions, methods, components) in isolation: does each part work correctly?
- Integration testing checks connected parts working together (front end + back end, back end + database): do the parts cooperate?
- User acceptance testing (UAT) checks the whole system against users' real needs, often with real users: does it do what the user actually wanted?
- The levels build up: unit (pieces), integration (parts together), UAT (whole system and users).
- Testing at multiple levels catches problems close to their source, early and cheaply, and pinpoints them.
- Memory hook: unit tests the pieces, integration tests the connections, UAT tests the whole system for the users, find bugs before evaluators do.