Phase 2 of 5  ·  Design & Modeling
Week 08 / 20   ·   Ch 8

Software
Testing

"Unit, Integration, System, Acceptance — explained with one real example"

📚 Ch 8 — Software Testing🔬 4 Test Levels🔴 TDD Cycle⏱ ~20 min read

🔍Concept Deep Dives

Click each concept to expand — real examples, diagrams, pros & cons.

🔬

Unit Testing

Test individual functions/methods in isolation. Fast, cheap, runs on every commit.

When to Use

Always — every function with meaningful logic should have unit tests.

Real-World Example

Testing a calculateTax(amount, rate) function with multiple inputs: 0%, 10%, negative values, edge cases.

✓ Advantages

  • Fast to run
  • Pinpoints exact failure location
  • No external dependencies needed

⚠ Watch Out

  • Doesn't test component interactions
  • Mocks can hide integration bugs
Function: calculateTax(100, 0.10) → 10 Function: calculateTax(0, 0.10) → 0 Function: calculateTax(-1, 0.10) → raise ValueError ✓ All pass = function works in isolation
🔗

Integration Testing

Test that components work correctly together — APIs, databases, services.

When to Use

After unit tests — test the contracts between components.

Real-World Example

Testing that the login controller correctly calls the auth service which correctly queries the database.

✓ Advantages

  • Catches interface mismatches
  • Tests real component interaction
  • Closer to production behavior

⚠ Watch Out

  • Slower than unit tests
  • Harder to set up (needs running services)
  • Flaky if using real external services
[LoginController] → [AuthService] → [UserRepository] → [DB] Integration test spans this entire chain
🌐

System Testing

Test the complete integrated system against requirements. End-to-end, black-box.

When to Use

After integration — test the whole system as users will use it.

Real-World Example

Testing a checkout flow from product selection → cart → payment → confirmation → email — in a staging environment.

✓ Advantages

  • Tests real user scenarios
  • Validates against requirements
  • Finds emergent defects

⚠ Watch Out

  • Slow and expensive
  • Hard to isolate failures
  • Environment setup complexity
User Story → Test Scenario → E2E Test 'As a customer, I can check out' → [UI click] → [API calls] → [DB] → [Email] → [Verify receipt]
🔴

Test-Driven Development (TDD)

Red → Green → Refactor. Write the test FIRST. Then write code to make it pass.

When to Use

Feature development where you want clean design + high confidence.

Real-World Example

'I need to parse a JWT' → write test for valid/invalid/expired tokens FIRST → then write the parser.

✓ Advantages

  • Forces clear interface design upfront
  • High test coverage by default
  • Refactoring confidence

⚠ Watch Out

  • Slower initial velocity
  • Requires discipline
  • Hard to apply to UI or legacy code
1. RED: Write a failing test 2. GREEN: Write minimum code to pass 3. REFACTOR: Clean up without breaking tests 4. Repeat for next requirement
👥

User Acceptance Testing

Testing by end-users to confirm the system meets their needs. Alpha, Beta, A/B testing.

When to Use

Before final release — validate with real users in real environments.

Real-World Example

Beta testing: ship to 1% of users, monitor for crashes and feedback before 100% rollout.

✓ Advantages

  • Real user validation
  • Catches usability issues
  • Business sign-off

⚠ Watch Out

  • Expensive and slow to arrange
  • Users may not test edge cases
  • Hard to reproduce bugs
Alpha: internal users (controlled environment) Beta: external users (real environment) A/B: compare versions with real users Acceptance: customer signs off on requirements

📋Quick Reference

θ Ch 8 Cheat Sheet — Software Testing
Unit Test
One function, isolated. Fast, cheap. Mock dependencies. Run on every commit.
Integration Test
Multiple components together. Tests contracts/interfaces. Needs real services.
System Test
Full system, black-box, end-to-end. Tests user scenarios vs. requirements.
Acceptance Test
Customer/user validates the system. Alpha → Beta → Sign-off.
TDD Cycle
Red (write failing test) → Green (minimum code to pass) → Refactor (clean up). Repeat.
Test Pyramid
Many unit tests, fewer integration tests, fewest E2E tests. Fast + reliable + cheap.
Release Testing
Independent team tests complete system before release. Requirements-based + scenarios + performance.
θ
Sommerville's Key Points — Ch 8
Author's own summary from the end of the chapter.
  • 1Testing is the primary quality assurance technique — validates that system meets requirements.
  • 2Development testing: unit, component, system. Done by developers during development.
  • 3Unit testing: test individual program units in isolation. Automated, fast.
  • 4Test-driven development: write tests before code. Red-Green-Refactor cycle.
  • 5Release testing: independent team validates the system before release.
  • 6User testing: alpha (internal), beta (external), acceptance testing.
  • 7Inspections and reviews complement testing — find different types of defects.

🧠Quiz — Test Yourself

Think through your answer first, then reveal.

Q1
Recall
Explain the test pyramid. Why should you have more unit tests than E2E tests?
Test pyramid: many unit tests at base, fewer integration tests in middle, fewest E2E at top. Unit tests are fast (ms), cheap, pinpoint failures. E2E tests are slow (minutes), flaky, expensive to maintain. Inverse pyramid = slow feedback, flaky CI, expensive maintenance.
Q2
Apply
What is the main benefit of TDD? What is the main cost?
Benefit: forces you to design the interface before implementation — leads to better, more testable design. High test coverage by default. Safe refactoring. Cost: slower initial velocity, requires discipline, hard to apply to UI code and legacy systems.
Q3
Analyze
What is the difference between a system test and an acceptance test?
System test: internal team tests the complete system against specification. Technical validation. Acceptance test: customer or end-users test the system to verify it meets their BUSINESS needs. Can pass system tests but fail acceptance (built the right spec, but the spec was wrong).
Up Next → Week 09
Software Evolution
Why companies still maintain 20-year-old systems
Continue → Week 09