Testing basics and the test pyramid

Why test?

Every change can break something that used to work: a refactor breaks the GST calculation, a new screen breaks login. Checking everything by hand before each release takes hours and still misses things. A test is a small program that runs part of your app with known inputs and checks the result. Once written, tests run in seconds, every time, and catch breakages before your users do.

Two places for tests

The test pyramid

          /\
         /UI\          few: end-to-end UI tests (slow, brittle, but realistic)
        /----\
       / Integ \       some: integration tests (repository + fake API, Room + DAO)
      /--------\
     /   Unit   \      many: unit tests (fast, focused, cheap to write)
    /------------\

• Unit test: checks one small unit (a function, a class) in isolation.
• Integration test: checks several units working together, such as a repository with a fake API and a real Room database.
• End-to-end (E2E) UI test: drives the app like a user, tapping buttons and checking screens.

What to test first

1. Business rules that cost money or trust if wrong: prices, taxes, discounts, limits.
2. ViewModel logic: given these events, the UI state becomes this.
3. Parsing and mapping: JSON to models, DTO to domain.
4. A few critical user journeys end to end: login, checkout.

Test doubles: fakes

Real dependencies (network, payment gateway, clock) make tests slow and unpredictable. A test double replaces them. A fake is a simple working implementation, such as a FakeOrderRepository that keeps orders in a list. This is why dependency injection (module 7) matters: a class that receives its dependencies can be given fakes in tests.

Good tests are

• Fast: they run in seconds, so you run them often.
• Independent: each test sets up its own data; order does not matter.
• Repeatable: same result every run (no real network, no real time).
• Readable: a good name says what is checked, for example totalIncludesGstWhenCouponApplied.

Common mistakes

• Only UI tests: slow, flaky, and hard to see what broke. Push logic down into testable classes.
• Tests that hit the real internet: fail whenever the network is slow.
• Testing implementation details (private functions) instead of behaviour.
• Never running tests. Run them before every commit, and in CI.