unit test       -> apakah logic kecil benar?
component test  -> apakah satu komponen benar dengan boundary terkontrol?
contract test   -> apakah service boundary compatible?
integration test-> apakah kode bekerja dengan dependency nyata?

Can a real user/system journey complete across deployed components?

slow
flaky
expensive
hard to debug
order-dependent
data-dependent
environment-dependent
owned-by-nobody

memberi signal yang dipercaya untuk mengambil keputusan release.

lebih mirip production
lebih banyak komponen nyata
lebih banyak failure mode nyata
lebih banyak latency
lebih banyak nondeterminism
lebih sulit diagnosa
lebih mahal dijalankan

user can submit regulatory case and see final accepted status
case escalation journey crosses API, workflow engine, event bus, database, notification service
login + authorization + main business action works after deployment
order checkout path still works after service mesh/routing/config change

validation rule for one field
all possible status transitions
all edge cases of date parsing
all pricing rule combinations
all failure branches of retry logic
all schema compatibility cases

Use E2E tests for journey confidence, not exhaustive correctness.

frontend broken
API broken
auth broken
database migration broken
Kafka lagging
workflow engine down
feature flag wrong
routing wrong
config wrong
secret expired
timeout too aggressive
test data polluted
browser automation flaky
environment unhealthy

Unit failure        -> usually points to one function/class.
Contract failure    -> usually points to boundary mismatch.
Integration failure -> usually points to service-dependency interaction.
E2E failure         -> says journey failed, diagnosis requires evidence.

E2E suite takes > 30 minutes on every PR
engineers rerun failed jobs until green
failures are ignored as flaky
one test failure blocks unrelated teams
nobody knows owner of failed journey
shared test data causes random failures
all tests depend on same staging environment
E2E tests assert internal database details
UI tests use CSS selectors that change often
sleep-based waits create random timing failures

1. unclear scope
2. missing lower-level tests
3. weak test data ownership
4. unstable environment
5. poor observability
6. no flakiness governance
7. every team adds tests but nobody removes tests
8. tests verify too many things at once

E2E should cover the narrow waist of critical journeys.

apakah deployment hidup dan core path bisa dilalui?

sedikit
cepat
jalan setelah deploy
blocking untuk release
coverage sempit

login -> create case -> submit -> see accepted status

apakah business journey utama berjalan across components?

lebih panjang dari smoke
bisa jalan PR/staging/nightly
punya owner jelas
punya test data dedicated

create case -> assign investigator -> request evidence -> approve escalation -> close case

mencegah bug produksi tertentu muncul lagi pada journey penting.

semua production bug dijadikan E2E test

Kalau bug bisa dicegah dengan unit/property/contract/integration, jangan jadikan E2E.

continuous verification di production dengan safe test account/data.

non-destructive
isolated tenant/account
rate limited
alerting-aware
observability-rich

backend workflow
service orchestration
case lifecycle
order lifecycle
payment lifecycle
eventual consistency
authorization boundary via token

lebih cepat
lebih stabil
lebih mudah didiagnosa
lebih dekat ke service contract

tidak membuktikan UI wiring
belum membuktikan browser behavior
belum membuktikan actual user interaction

critical user-facing flows
login/session/cookie behavior
form rendering and submission
navigation
role-based visibility
frontend-backend wiring

paling dekat dengan human user path
mendeteksi wiring bug antara UI dan backend

lebih lambat
lebih rentan flake
lebih sulit debug
selector bisa rapuh
async rendering membuat wait rumit

Most journey E2E should be API-level.
A very small number should be UI-level.

pilih beberapa perjalanan kritikal yang melewati jalur representatif
uji dengan data dan environment production-like
jangan enumerasi semua variasi
pindahkan variasi ke layer bawah

Ada 84 validation rules untuk case submission.
Jangan buat 84 UI E2E tests.

Buat:
- unit/property tests untuk validation rules
- contract tests untuk API error shape
- integration tests untuk persistence constraint
- 1 UI E2E untuk happy path submission
- 1 UI E2E untuk representative validation failure

1. declare journey intent
2. create isolated test data
3. authenticate with controlled identity
4. execute user/system actions
5. wait for externally observable state
6. assert business outcome
7. collect diagnostics on failure
8. cleanup or mark data disposable

@Tag("e2e")
class CaseSubmissionJourneyE2ETest {

    private final CaseApi caseApi = ApiClients.caseApi();
    private final AuthClient auth = ApiClients.auth();

    @Test
    void officerCanSubmitCaseAndSeeAcceptedStatus() {
        var runId = RunId.newRunId();
        var token = auth.loginAs("officer-e2e");

        var draft = caseApi.createDraft(token, new CreateCaseRequest(
            "CASE-" + runId.value(),
            "MARKET_ABUSE",
            "LOW",
            List.of(new PartyRequest("ACME-" + runId.value()))
        ));

        caseApi.submit(token, draft.caseId());

        await().atMost(Duration.ofSeconds(30))
            .pollInterval(Duration.ofMillis(500))
            .untilAsserted(() -> {
                var view = caseApi.getCase(token, draft.caseId());
                assertThat(view.status()).isEqualTo("ACCEPTED");
                assertThat(view.auditTrail())
                    .extracting(AuditEntry::action)
                    .contains("CASE_SUBMITTED", "CASE_ACCEPTED");
            });
    }
}

runId unique
identity controlled
assertion business-level
async wait uses condition, not Thread.sleep
no internal database assertion

assertThat(database.query("select workflow_state from wf_case where id=?", caseId))
    .isEqualTo("S7_AWAITING_DISPATCH");

E2E test sekarang tahu schema internal
refactor database memecahkan test walaupun behavior benar
failure tidak merepresentasikan user-visible/system-visible outcome

var view = caseApi.getCase(token, caseId);
assertThat(view.status()).isEqualTo("AWAITING_DISPATCH");
assertThat(view.availableActions()).contains("ASSIGN_INVESTIGATOR");

var notification = notificationProbe.findByCorrelationId(correlationId);
assertThat(notification.type()).isEqualTo("CASE_DISPATCH_READY");

Good probe: API, event topic, notification sink, audit endpoint, exported report.
Risky probe: private table, private class, internal cache.

all tests use same user
all tests use same account/customer/case
manual staging data reused forever
tests depend on data created by previous test
cleanup deletes shared data

1. every test run has runId
2. every entity name includes runId
3. test users are dedicated
4. test tenant/account is dedicated
5. data is disposable
6. cleanup is best-effort, not required for correctness
7. assertions filter by correlation/runId

public record RunId(String value) {
    public static RunId newRunId() {
        return new RunId("e2e-" + Instant.now().toEpochMilli() + "-" + UUID.randomUUID());
    }
}

case external reference
customer name
idempotency key
correlation id
request header
audit metadata
log context

var correlationId = runId.value();
request.header("X-Correlation-Id", correlationId);
request.header("Idempotency-Key", runId.value() + ":submit-case");

login -> click admin -> create user -> create account -> create case -> open case -> test one button

terlalu panjang
terlalu banyak failure cause
lambat
sulit debug

setup via API/test fixture endpoint
then test UI behavior under target state

@BeforeEach
void setup() {
    testDataApi.createCaseReadyForAssignment(runId);
}

@Test
void investigatorCanAssignCaseFromUi() {
    loginPage.loginAs("supervisor-e2e");
    casePage.open(runId.caseReference());
    casePage.assignTo("investigator-e2e");
    casePage.expectStatus("ASSIGNED");
}

POST /test-fixtures/cases/ready-for-assignment
POST /test-fixtures/users/e2e-session
POST /test-fixtures/reset-tenant

1. endpoint only enabled in non-prod, unless synthetic production explicitly designed
2. protected by strong auth
3. audited
4. cannot create impossible state unless test explicitly needs impossible state
5. owned by platform/test infrastructure team
6. schema/versioned like normal API

button:nth-child(3)
.main > div > div > span
text=Submit

role-based locator
label-based locator
stable test id for critical controls

page.getByRole(AriaRole.BUTTON,
    new Page.GetByRoleOptions().setName("Submit case")
).click();

page.getByTestId("case-status").textContent();

Prefer user-facing semantics.
Use test ids for stable business-critical elements.
Avoid CSS structure selectors.

critical
hard to locate semantically
likely to be visually refactored
business meaningful

Thread.sleep(5000);
assertThat(page.locator("#status").textContent()).isEqualTo("ACCEPTED");

kalau sistem selesai 100 ms, test membuang waktu
kalau sistem selesai 6 detik, test gagal random

assertThat(page.getByTestId("case-status"))
    .hasText("ACCEPTED", new LocatorAssertions.HasTextOptions()
        .setTimeout(30_000));

await().atMost(Duration.ofSeconds(30))
    .pollInterval(Duration.ofMillis(500))
    .untilAsserted(() -> {
        var status = caseApi.getCase(token, caseId).status();
        assertThat(status).isEqualTo("ACCEPTED");
    });

Wait for condition, not time.

HTTP request returns 202
workflow engine advances later
Kafka event processed later
notification sent later
projection updated later

caseApi.submit(token, caseId);
assertThat(caseApi.getCase(token, caseId).status()).isEqualTo("ACCEPTED");

caseApi.submit(token, caseId);

await().atMost(Duration.ofSeconds(45))
    .untilAsserted(() -> {
        var view = caseApi.getCase(token, caseId);
        assertThat(view.status()).isEqualTo("ACCEPTED");
        assertThat(view.auditTrail())
            .extracting(AuditEntry::action)
            .contains("CASE_ACCEPTED");
    });

case submission projection should update within 10 seconds p99 in staging

30 seconds hard timeout
poll every 500 ms
record actual latency as metric

X-Correlation-Id: e2e-20260702-abc123

API logs
workflow variables
Kafka headers
audit trail
notification metadata
trace spans
E2E report artifact

search logs by correlationId
open distributed trace
inspect event stream
inspect audit trail

request/response summary
status code
correlation ID
last known business status
relevant audit trail
recent events by correlation ID
trace URL
logs URL/query

screenshot
video/trace when possible
browser console logs
network HAR or request summary
DOM snapshot for failure point

Journey: officerCanSubmitCaseAndSeeAcceptedStatus
Run ID: e2e-1720000000-a17f
Case ID: CASE-123
Expected: ACCEPTED within 30s
Actual: SUBMITTED after 30s
Last audit actions: CASE_CREATED, CASE_SUBMITTED
Last workflow state: WAITING_FOR_RISK_SCORE
Trace: <trace-url>
Kafka events found: CaseSubmitted, RiskScoreRequested
Missing: RiskScoreCompleted

expected ACCEPTED but was SUBMITTED

developer debugging
container-compose stack
small API journey

not production-like
config differs
limited dependencies

change-specific validation
service branch deployment
contract/integration with deployed stack

expensive
slow to provision
shared infrastructure constraints

release candidate validation
cross-team journey

shared state
environment contention
test interference
configuration drift

continuous post-deploy confidence
real routing/auth/config verification

must be non-destructive
must not pollute business data
must not page teams for test artifact failure unless meaningful

PR: unit + component + contract + selected integration
merge/main: integration + selected API E2E
release candidate: smoke UI/API E2E + journey E2E
post-deploy: synthetic smoke E2E
nightly: broader journey E2E

business owner
engineering owner
primary service owner
failure triage channel
expected runtime
expected environment
flakiness threshold
retirement rule

@Tag("e2e")
@Tag("journey:case-submission")
@Tag("owner:case-platform")
@Tag("criticality:release-blocking")
class CaseSubmissionE2ETest {
}

journey: case-submission
owner: case-platform
criticality: release-blocking
environment: staging, production-synthetic
max_runtime_seconds: 60
failure_channel: '#case-platform-ci'

release-blocking smoke
release-blocking critical journey
non-blocking exploratory journey
nightly regression journey
production synthetic alerting

Blocking tests must be few, reliable, fast, owned.
Non-blocking tests may be broader but must still be actionable.

quarantined_at
owner
reason
last_seen_failure
fix_deadline
removal_if_not_fixed

1. timing: sleep, race, async wait wrong
2. data: shared mutable data, polluted state
3. environment: unstable dependency, staging deploy in progress
4. order dependency: test relies on previous test
5. concurrency: parallel tests update same entity
6. selector: UI locator unstable
7. external service: third-party sandbox unreliable
8. resource: CPU/memory/network saturation in CI
9. randomness: uncontrolled random data
10. clock/timezone: date assumptions

infrastructure setup instability
known transient environment health checks
non-blocking diagnostic rerun classification

business assertion failure
race condition
idempotency bug
timeout bug

1. no automatic retry for release-blocking smoke by default
2. one diagnostic rerun allowed to classify flake, not hide failure
3. if rerun passes, mark as flaky and create owner ticket
4. if same test flakes above threshold, quarantine or delete
5. never allow infinite rerun until green

rerun-until-green converts uncertainty into false confidence.

first run: failed
rerun: passed
result: flaky, release decision requires policy

login
create customer
create account
create case
submit case
assign case
upload evidence
request approval
approve escalation
send notification
generate report
close case
export archive

Smoke: login -> create case -> submit -> accepted
Journey A: submitted case -> assign investigator
Journey B: assigned case -> upload evidence -> request approval
Journey C: approved case -> close -> archive available

runtime
failure localization
parallelization
ownership

payment sandbox
identity provider
email provider
SMS provider
credit bureau
regulator endpoint
market data feed

Should E2E call the real external dependency?

integration is critical
sandbox is stable
cost is acceptable
rate limits are safe
data is safe
failure is actionable by your team or agreement exists

use controlled simulator
verify provider contract separately
run real external integration on schedule, not every PR

one happy-path login/session journey
one role-based access journey for critical boundary
one token/API-auth journey for service integration

permission matrix -> unit/property tests
API authorization -> component/integration tests
critical UI visibility -> few UI E2E tests

e2e-officer
e2e-supervisor
e2e-investigator
e2e-admin-readonly

credentials managed as secrets
no personal accounts
no shared mutation unless isolated by runId
audit marks synthetic/test identity

API projection status
public event emitted
notification received by sink
audit trail entry
workflow task created
read model updated

read-only event probe by correlation ID
test notification sink
audit API
workflow query API

sleep then consume from production topic destructively
reading private internal topic without ownership
asserting exact sequence if only causal outcome matters

must happen before
may happen eventually
may happen in any order
must happen exactly once
must not happen

await().atMost(Duration.ofSeconds(30)).untilAsserted(() -> {
    var events = eventProbe.eventsByCorrelationId(correlationId);

    assertThat(events).extracting(EventView::type)
        .contains("CaseSubmitted", "CaseAccepted")
        .doesNotContain("CaseRejected");

    assertThat(events.stream()
        .filter(e -> e.type().equals("CaseAccepted"))
        .count()).isEqualTo(1);
});

data migration verification
integration-level persistence behavior
test fixture diagnostics
internal admin/reporting journey where database is the product boundary

normal user journey asserting private table state
asserting implementation-specific workflow table
asserting exact row count in shared environment

Is this an observable business contract or private implementation?
Can the same evidence be exposed through API/audit/event/probe?
Will this break during valid refactor?

PR catches local correctness and boundary drift.
Main/release catches deployed journey issues.
Production synthetic catches environment/config/routing drift.

PR selected E2E: 0-3 minutes
main API smoke: 3-8 minutes
staging critical journeys: 5-15 minutes
nightly broader E2E: 30-90 minutes
production synthetic: continuous, small probes

too many tests?
long setup?
sleep waits?
shared environment bottleneck?
slow login repeated?
unnecessary UI coverage?
external sandbox latency?

unique runId
unique entity names
independent users or role sessions
no global mutable config changes
no shared cleanup that deletes others' data
idempotent fixture setup

shard by journey owner
shard by estimated duration
avoid putting all long tests in one shard
keep critical smoke separate

@Tag("e2e")
@Tag("e2e:smoke")
@Tag("e2e:ui")
@Tag("e2e:api")
@Tag("owner:case-platform")

<profile>
  <id>e2e</id>
  <properties>
    <groups>e2e</groups>
  </properties>
</profile>

check application health endpoints
check database migration version
check Kafka broker/topic health
check auth provider health
check required feature flags
check test fixture API version
check deployment version/build SHA

environment failure

business journey regression

1. Did environment health pass?
2. Did authentication/setup succeed?
3. Did action request succeed?
4. Did async processing start?
5. Did expected event/audit state appear?
6. Did projection/UI update?
7. Is failure reproducible locally/staging?
8. Is failure caused by test data collision?
9. Is failure caused by known external dependency?
10. Is this a product bug, environment bug, or test bug?

PRODUCT_REGRESSION
TEST_BUG
ENVIRONMENT_FAILURE
FLAKY_TIMING
DATA_COLLISION
EXTERNAL_DEPENDENCY
UNKNOWN

case intake -> risk scoring -> triage -> assignment -> evidence request -> approval -> closure

100 UI tests for all case types, all risks, all role combinations, all validation errors.

Validation matrix         -> unit/property tests
Transition matrix         -> state-machine tests
Role permission matrix    -> component/API authorization tests
Event schema compatibility-> contract tests
Persistence constraints   -> integration tests
Kafka idempotency         -> integration/property tests
Critical journey          -> API E2E
Main UI path              -> 1-3 UI E2E smoke tests
Production config         -> synthetic smoke

1. Officer submits valid case and sees accepted status.
2. Supervisor assigns accepted case to investigator.
3. Investigator requests escalation approval and supervisor approves.
4. Closed case appears in archive/report export.

@Tag("e2e")
@Tag("e2e:api")
@Tag("journey:case-escalation")
class CaseEscalationJourneyE2ETest {

    private final AuthClient auth = Clients.auth();
    private final CaseApi cases = Clients.cases();
    private final AssignmentApi assignments = Clients.assignments();
    private final EventProbe events = Clients.eventProbe();

    @Test
    void investigatorCanRequestEscalationAndSupervisorCanApprove() {
        var runId = RunId.newRunId();
        var officer = auth.loginAs("officer-e2e");
        var investigator = auth.loginAs("investigator-e2e");
        var supervisor = auth.loginAs("supervisor-e2e");

        var caseId = cases.createAndSubmit(officer, runId.caseReference());

        awaitCaseStatus(caseId, "ACCEPTED");

        assignments.assign(supervisor, caseId, "investigator-e2e");

        cases.requestEscalation(investigator, caseId, new EscalationRequest(
            "POTENTIAL_SYSTEMIC_RISK",
            "Evidence indicates multi-entity pattern"
        ));

        awaitCaseStatus(caseId, "ESCALATION_PENDING_APPROVAL");

        cases.approveEscalation(supervisor, caseId);

        awaitCaseStatus(caseId, "ESCALATED");

        await().atMost(Duration.ofSeconds(30)).untilAsserted(() -> {
            assertThat(events.byCorrelationId(runId.value()))
                .extracting(EventView::type)
                .contains("CaseEscalationRequested", "CaseEscalationApproved");
        });
    }

    private void awaitCaseStatus(String caseId, String expected) {
        await().atMost(Duration.ofSeconds(30))
            .pollInterval(Duration.ofMillis(500))
            .untilAsserted(() -> {
                assertThat(cases.get(caseId).status()).isEqualTo(expected);
            });
    }
}

business journey is real
assertions are at observable boundaries
timing is condition-based
correlation ID ties request/event/log
roles are explicit

@Tag("e2e")
@Tag("e2e:ui")
@Tag("journey:case-submission-ui")
class CaseSubmissionUiE2ETest {

    @Test
    void officerCanSubmitCaseThroughUi(Page page) {
        var runId = RunId.newRunId();

        LoginPage login = new LoginPage(page);
        CaseFormPage form = new CaseFormPage(page);
        CaseViewPage view = new CaseViewPage(page);

        login.loginAs("officer-e2e");

        form.openNewCase();
        form.enterReference(runId.caseReference());
        form.selectType("Market Abuse");
        form.selectPriority("Low");
        form.addParty("ACME " + runId.value());
        form.submit();

        view.expectStatus("Accepted");
        view.expectAuditAction("Case submitted");
    }
}

form.completeEverything();

form.enterReference(...);
form.selectType(...);
form.submit();

loginAs(role)
openNewCase()
enterReference(reference)
submit()
expectStatus(status)

doHappyPath()
createCaseAndApproveEverything()
magicSetup()
clickThirdButton()

locators
wait mechanics
common UI interactions
semantic assertions

entire business journey
hidden data creation
branching test logic
uncontrolled retry

UI E2E checks every validation branch.

move validation matrix to unit/property tests.
keep one representative UI validation smoke.

Test B depends on data from Test A.

each test creates its own state or uses fixture endpoint.

all tests mutate e2e-admin account preferences/session/cart.

separate accounts per role/journey or unique run data.

Thread.sleep everywhere.

condition waits with timeout and diagnostics.

one E2E asserts UI text, DB rows, Kafka payloads, email content, report file, and all audit details.

assert minimal business outcome.
move detailed checks to lower layers.

journey no longer exists
journey is covered by better lower-level tests and no longer needs E2E
failure has not been actionable for long period
ownership disappeared
test is permanently quarantined
cost exceeds risk reduction

E2E tests are for journey confidence, not exhaustive correctness.

The broader the test scope, the more discipline you need around data, diagnostics, and ownership.

A small trusted E2E suite is better than a large ignored one.

If a failure cannot be diagnosed, the E2E test is incomplete.