Component (Unit) Testing

Why it matters

Many defects, such as a wrong formula, a missed condition or an unhandled empty value, live inside a single component. When a component test finds one, its location is known at once: the failing test names the function and the input. When the same defect is found later through the user interface, it needs a bug report, reproduction and investigation across several layers before anyone knows where it is.

For a tester, component tests are the first safety net in the team's test strategy. Knowing what they cover lets you aim system and acceptance tests at what only those levels can find, instead of repeating checks that already run on every commit. Knowing what they cannot cover, the behaviour hidden behind stubs and mocks, tells you where integration risk remains.

What a component test is, and who writes it

The ISTQB Foundation syllabus v4.0 describes component testing as focusing on testing components in isolation. It often needs specific support, such as a test harness or a unit test framework, and it is normally performed by developers in their own development environment. In practice its test basis is the material closest to the code: the component's detailed design or specification, the code itself and the data model.

What counts as a component depends on the code. In a back end it is usually a function or a class; in a front end it can be a single UI component such as a date picker. Teams also use the words differently: some say "component test" for something larger, such as one whole service with everything around it replaced, so ask what your team means before you compare numbers.

Most unit tests share a three-part shape, often called Arrange, Act, Assert: prepare the inputs and dependencies, call the component once, and compare the result with the expected value. A good unit test is fast, checks one behaviour, gives the same result on every machine and every run, and has a name that states the expected behaviour.

Isolation and test doubles: stubs, mocks and the rest

Real components depend on other things: a database, a payment provider, the current date, another team's service. To test one component in isolation, the developer replaces those dependencies with test doubles, a general term from Gerard Meszaros named after the stunt doubles of film. Isolation makes the test fast and repeatable, and it makes situations testable that are hard to create with the real dependency, such as a timeout or an expired coupon.

The ISTQB glossary uses two older terms: a stub replaces a component that the component under test calls, and a driver calls the component under test in place of its real caller. Drivers and stubs together make up the test harness. The finer distinctions below come from Meszaros, as described by Martin Fowler:

• Dummy: passed only to fill a parameter list; it is never actually used.
• Stub: gives canned answers to the calls made during the test, for example "SAVE10 is a 10% coupon". The test then checks the component's result (state verification).
• Spy: a stub that also records how it was called, so the test can inspect the calls afterwards.
• Mock: pre-programmed with the calls it expects, and the test fails if they do not happen, for example "send exactly one confirmation e-mail" (behaviour verification).
• Fake: a working but simplified implementation, such as an in-memory database.

Try it: Mock API Response Generator Try it: Mock Error Response Generator

Worked example: a coupon component with a stubbed service

Requirement: "A valid coupon takes its percentage off the basket subtotal, up to the coupon's maximum discount. An unknown or expired coupon leaves the subtotal unchanged and is reported as invalid." The component applyCoupon looks up the code through couponApi, which in production calls a remote coupon service. You do not need to know JavaScript to read the code below: await waits for an answer, test(...) defines one named test, and expect(actual).toEqual(expected) compares the actual result with the expected one.

In the tests, couponApi is a stub that knows one coupon, SAVE10: 10% off, at most 50.00 SAR. The results no longer depend on the real service being up, on which coupons exist in a shared database, or on today's date. The developer writes one test per rule, each with an expected value worked out from the requirement:

• 200.00 with SAVE10 → total 180.00 (10% is 20.00, below the cap).
• 1000.00 with SAVE10 → total 950.00 (10% would be 100.00, so the 50.00 cap applies).
• A stub that returns the coupon marked as expired → total 200.00, error COUPON_INVALID.
• A stub that finds nothing for the code FAKE99 → total 200.00, error COUPON_INVALID.
• A stub that throws "service unavailable" → the error escapes from applyCoupon. The requirement never says what checkout should do then, so the tester takes that question to the product owner. A double made this path testable in seconds; with the real service it is hard to produce on purpose.

// Component under test
async function applyCoupon(code, subtotal, couponApi) {
  const coupon = await couponApi.lookup(code);
  if (!coupon || coupon.expired) return { total: subtotal, error: 'COUPON_INVALID' };
  const discount = Math.min((subtotal * coupon.percent) / 100, coupon.maxDiscount);
  return { total: subtotal - discount, error: null };
}

// Arrange: a stub gives a canned answer instead of the remote coupon service
const couponApi = {
  lookup: async (code) =>
    code === 'SAVE10' ? { percent: 10, maxDiscount: 50, expired: false } : null,
};

test('SAVE10 takes 10% off a 200.00 basket', async () => {
  const result = await applyCoupon('SAVE10', 200, couponApi);  // Act
  expect(result).toEqual({ total: 180, error: null });          // Assert
});

Test-driven development: the test comes first

The ISTQB syllabus lists test-driven development (TDD), together with acceptance test-driven development and behaviour-driven development, among the approaches in which tests drive development. In TDD the developer works in short cycles: write a component test for the next small piece of behaviour and see it fail, write just enough code to make it pass, then improve the structure of the code while all tests stay green. Practitioners call the cycle red, green, refactor.

In the coupon example, the developer would first write the 180.00 test against a function that does not exist yet, then the cap test, then the expired-coupon test, adding code only to make each one pass. TDD leaves behind a suite of fast regression tests and pushes the design towards small components that are easy to isolate. It is a way of developing that applies early testing; it does not replace the other test levels, because the developer's tests can only check the developer's own understanding of the requirement.

What a tester should know and review

Testers rarely own the unit tests, but reading them is one of the cheapest reviews a team can do. You do not have to write the code yourself to ask good questions; the test names and inputs usually tell you what was checked. Look at:

• Rules: map each acceptance criterion to a test. A rule without a test, such as a cap or a default value, is a gap at this level.
• Inputs: empty values, zero, the exact limit named in the requirement and invalid formats, not only one typical value.
• Assertions: each test compares the result with a value worked out from the requirement, not copied from the code's output and not just "no error was thrown".
• Doubles: stubs return what the real dependency really returns, including its errors and empty results. Later, integration tests and contract tests (tests that check that the real service still answers the way the doubles assume) confirm that they match.
• Independence: no dependence on run order, the real clock, random values or shared data. A test that passes and fails without any code change is flaky.
• Results: know where each build's unit test report is; a build whose unit tests failed or were skipped is not ready for system testing.

Try it: Requirements → Test Cases Try it: Boundary Value Generator

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• Test Double (Martin Fowler)martinfowler.com · 2006Gerard Meszaros's vocabulary for test doubles — dummy, fake, stub, spy and mock — as summarised by Martin Fowler.
• Mocks Aren't Stubs (Martin Fowler)martinfowler.com · 2007The difference between state verification and behaviour verification, and between the classical and mockist styles of test-driven development.