E2E Critical User Journeys — Implementation Plan

Date: 2026-05-10
Scope: Backend E2E test suite for all 12 critical user journeys
Strategy: Risk-first theo phase

1) Mục tiêu

Thiết lập bộ E2E tests đủ mạnh để:

  • Chặn regression cho auth, RBAC, multi-tenant isolation và telemetry flow.
  • Bảo vệ các luồng nghiệp vụ cốt lõi khi thêm tính năng mới.
  • Cung cấp smoke suite chạy nhanh trước merge, full suite chạy theo lịch/PR quan trọng.

2) Nguyên tắc thực hiện

  • Test theo hành vi API contract (status code, response schema, side effects).
  • Ưu tiên deterministic data (fixture rõ ràng, cleanup rõ ràng).
  • Tách test data theo organization để kiểm chứng isolation.
  • Không mock các thành phần xuyên luồng business quan trọng (DB/auth/rbac path).
  • Mỗi journey có ít nhất 1 happy-path + 1 negative-path.

3) Phân phase triển khai (Risk-first)

Phase 1 — Security & Data Isolation (ưu tiên cao nhất)

Mục tiêu: chặn data leak và authorization bug.

Journeys:

  1. Auth cơ bản: register → login → profile → refresh → logout
  2. RBAC enforcement: đúng role thì pass, sai role thì 403
  3. Multi-tenant isolation: org A không truy cập/sửa dữ liệu org B
  4. Critical error contract: 401/403/404/422 trả đúng theo tình huống

Deliverables:

  • Bộ test auth/rbac/isolation chuẩn hóa fixture theo 2 organizations.
  • Shared helpers cho token, seed user-role-permission, request wrappers.
  • Baseline report: pass rate + execution time.

Estimate: 3–4 ngày dev.

Phase 2 — Core Business Flows

Mục tiêu: bảo vệ luồng nghiệp vụ vận hành hằng ngày.

Journeys:
5. Onboarding organization: tạo org + user đầu tiên + quyền mặc định
6. Farm management: create/update/list area/pond với pagination/filter theo org
7. Device lifecycle: register → assign pond/area → activate/deactivate
8. Telemetry ingestion (valid payload): ingest → persist → query latest/range
9. Telemetry invalid payload: reject đúng, không ghi dữ liệu lỗi

Deliverables:

  • E2E suite cho farm/devices/telemetry với test matrix hợp lệ/không hợp lệ.
  • Data factory cho farm-device-telemetry để tái sử dụng.

Estimate: 4–5 ngày dev.

Phase 3 — Aggregation, Automation & Release Hardening

Mục tiêu: bảo vệ lớp tổng hợp dữ liệu và tự động hóa.

Journeys:
10. Dashboard aggregation: response tổng hợp đúng khi có telemetry
11. Automation rule flow: tạo rule → telemetry vượt ngưỡng → trigger đúng hành động
12. Release smoke journey: happy path tối thiểu chạy nhanh trước merge

Deliverables:

  • E2E dashboard/automation đầy đủ assertion side effects.
  • Smoke suite riêng (tag hoặc file group) với runtime mục tiêu <= 5–7 phút.

Estimate: 3–4 ngày dev.

4) Task breakdown chi tiết cho developer

A. Nâng nền tảng test (Day 1)

  1. Rà lại cấu trúc hiện có trong backend/test/** và chuẩn naming mới.
  2. Tạo/thống nhất helper:
    • auth.helper (register/login/refresh/logout)
    • tenant.helper (seed org A/B, users, roles)
    • request.helper (HTTP client wrapper, headers/token)
  3. Thiết lập cleanup strategy:
    • Cách 1: transaction rollback per test (nếu phù hợp)
    • Cách 2: truncate có kiểm soát theo test module
  4. Chuẩn hóa test fixtures cho telemetry payload hợp lệ/không hợp lệ.

B. Implement tests theo phase

  • Thực hiện lần lượt Phase 1 → Phase 2 → Phase 3.
  • Mỗi journey:
    • 1 test happy path
    • 1–2 test negative path
    • Assertion gồm status, body, và DB side effect (khi cần)

C. Ổn định CI

  1. Tách smoke/full suites:
    • Smoke: auth + rbac + multi-tenant + telemetry ingest cơ bản
    • Full: toàn bộ 12 journeys
  2. Định nghĩa điều kiện chạy:
    • Smoke: mỗi PR
    • Full: nightly hoặc PR critical labels
  3. Thêm test report artifact (junit hoặc tương đương).

5) Definition of Done (DoD)

  • Bao phủ đủ 12 journeys theo danh sách.
  • Mỗi journey có ít nhất 1 happy + 1 negative test.
  • Không flaky trong 3 lần chạy liên tiếp local/CI.
  • Smoke suite runtime <= 7 phút.
  • Full suite runtime trong ngưỡng CI chấp nhận được (đề xuất <= 20 phút).
  • Tài liệu runbook ngắn cho dev mới: cách chạy smoke/full, cách debug fail.

6) Rủi ro & cách giảm thiểu

  1. Flaky do phụ thuộc thời gian/async

    • Giảm thiểu: freeze time hoặc retry có kiểm soát cho assert eventual consistency.

  2. Dữ liệu test chồng chéo giữa test cases

    • Giảm thiểu: unique namespace theo test run + cleanup chặt.

  3. Runtime suite tăng quá cao

    • Giảm thiểu: ưu tiên smoke nhỏ, gom setup dùng chung, tránh seed dư.

  4. Mismatch giữa local và CI environment

    • Giảm thiểu: đồng nhất env vars + service dependencies qua docker compose profile test.

7) Thứ tự ưu tiên file/work items

Ưu tiên chỉnh sửa/đầu tư trước:

  1. backend/test/auth/*
  2. backend/test/rbac/*
  3. backend/test/**/multi-tenant* (tạo mới nếu thiếu)
  4. backend/test/telemetry/*
  5. backend/test/dashboard/*
  6. backend/test/automation/*
  7. shared helpers trong backend/test/helpers/* (tạo/chuẩn hóa)

8) Kế hoạch giao việc đề xuất (2 developers)

  • Dev A (Security lane): Phase 1 + smoke suite.
  • Dev B (Business lane): Phase 2 trước, sau đó phối hợp Phase 3.
  • Cả hai cùng thống nhất helper/fixtures ngay Day 1 để tránh divergence.

9) Checklist nghiệm thu cho reviewer

  • Có chứng cứ chạy pass smoke suite trên PR.
  • Có chứng cứ chạy pass full suite (ít nhất 1 lần trên CI).
  • Review assertions đã kiểm tra đúng isolation theo organizationId.
  • Review negative tests có kiểm lỗi quyền và input invalid.
  • Không có test phụ thuộc thứ tự chạy.

10) Lệnh chạy tham chiếu

  • Backend E2E suite: bun run test:e2e (trong backend/)
  • Chạy file cụ thể: bun test -- test/<path-to-file>.e2e-spec.ts

Handoff Note cho Developer

Bắt đầu từ Phase 1 và hoàn tất smoke suite trước khi mở rộng sang Phase 2/3. Nếu phát hiện flaky, ưu tiên sửa độ ổn định test framework/helpers trước khi thêm test mới.