Java SE 21 — 1Z0-830

Appearance

Lesson 01 · Test Pyramid & Strategy ​

Beyond the 1Z0-830 exam

The exam tests Java; this lesson tests your judgement about testing: how much of each kind of test to write, and what each layer is actually good at. Get the shape wrong and the suite is either slow and flaky or fast but unconvincing.

Objectives

After this lesson you will be able to:

  • Describe the test pyramid and what each layer covers.
  • Avoid the ice-cream-cone anti-pattern.
  • Decide what to test where, and what not to test at all.

The pyramid ​

        /\        E2E / UI        — few:   slow, brittle, high confidence in the whole system
       /  \
      /----\      Integration     — some:  real DB/HTTP/wiring, medium speed
     /      \
    /--------\    Unit            — many:  milliseconds, isolated, pinpoint failures
LayerScopeSpeedCountGood at
Unitone class/method, collaborators doubledmsmostlogic, edge cases, fast feedback
Integrationseveral units + a real resource (DB, HTTP)10s–100s msfewerwiring, SQL, serialization, config
E2Ethe whole system through its real UI/APIseconds+fewestcritical user journeys

The shape matters because cost and flakiness rise as you go up, while pinpoint diagnosis falls. A unit failure names the broken method; an E2E failure says "checkout broke" and leaves you hunting.

The ice-cream cone (anti-pattern) ​

    \--------/   many slow E2E + manual tests
     \      /
      \----/     some integration
       \  /
        \/       few unit tests

Inverting the pyramid — mostly slow end-to-end and manual tests, few unit tests — gives a suite that's slow, flaky, and expensive to maintain, with feedback measured in minutes. Teams drift here because E2E tests feel "more real"; the cost shows up later as a CI run nobody trusts.

What to test where ​

  • Business logic, calculations, edge cases, error paths → unit. Cheapest place to be thorough.
  • SQL/queries, ORM mapping, JSON (de)serialization, framework wiring, transactions → integration. These only "work" against the real thing; a mock would just re-assert your assumptions.
  • A few critical end-to-end journeys → E2E. Login→buy→confirm. Not every permutation — pick the paths whose breakage would be a real incident.

Gotcha

Don't test the framework or the language. Tests that assert a getter returns what you set, that JUnit runs, or that the JDK's List.of is immutable add maintenance with no signal. Test your logic and your integrations.

SDET note

This pyramid is the backbone of Part B's testing track: Module 14 gave you the unit layer; Module 16 covers integration with real databases (Testcontainers); Modules 17–18 cover API and UI tests. Tag the layers (@Tag("unit") / @Tag("integration")) so the fast base runs on every push and the slow top runs less often (Module 20).

Test doubles and the pyramid ​

Lower layers lean on doubles (Module 14) to stay fast and isolated; higher layers use fewer doubles and more real components — that's the point of integration/E2E. A useful rule: mock at the architectural boundary you don't own (a third-party HTTP API), use the real thing for what you do own and can run cheaply (your repository against an in-memory or containerized DB).

Key Takeaways ​

  • The pyramid: many fast unit tests, fewer integration, fewest slow E2E — cost and flakiness rise with each layer, diagnosis precision falls.
  • Avoid the ice-cream cone: a suite dominated by slow E2E/manual tests is slow and untrusted.
  • What to test where: logic/edge cases → unit; SQL/serialization/wiring → integration; a few critical journeys → E2E.
  • Don't test the framework or language — only your own logic and integrations.
  • Higher layers use fewer doubles; mock at boundaries you don't own.

Lesson Quiz ​

Lesson Quiz · Test Pyramid & Strategy0 / 5

  1. Which layer should have the MOST tests?

    • AE2E/UI
    • BIntegration
    • CUnit
    • DManual

  2. Why are E2E tests kept few?

    • AThey're hard to write only
    • BThey're slow, brittle, and give imprecise failure diagnosis
    • CThey can't find real bugs
    • DJUnit can't run them

  3. The ice-cream-cone anti-pattern is…

    • AToo many unit tests
    • BAn inverted pyramid dominated by slow E2E and manual testing
    • CRunning tests in parallel
    • DUsing AssertJ

  4. Where do you best test that a SQL query returns the right rows?

    • AA pure unit test with everything mocked
    • BAn integration test against a real (e.g. in-memory/containerized) database
    • CAn E2E UI test
    • DManual testing

  5. Which is generally NOT worth a test?

    • AA business rule with edge cases
    • BA trivial getter that returns the field you set, or that the JDK/framework behaves as documented
    • CJSON deserialization of your DTOs
    • DAn error path in your service

Next: Data-Driven Tests & Fixtures. This module's lab is in labs/src/main/java/com/jse21/m15_architecture/.