@edupia-tutor/spec-driven-docs 0.14.0 → 0.14.2

package/commands/dev-gen-test.tmpl

@@ -1,15 +1,15 @@
-# /dev-gen-test — Generate Dev Self-Check Tests
+# /dev-gen-test — Sinh Dev Self-Check Tests
 
-> **Scope — dev self-check (smoke), not the official test suite.** These tests let the
-> developer quickly verify their own generated code against the BDD scenarios. They are a
-> developer self-check, **not** the QC/dev-team's authoritative test suite (that has its
-> own separate flow, implemented elsewhere). Results surface to the Living Docs dashboard
-> as a **dev self-test** signal so QC can see the dev already ran their own checks.
+> **Scope — dev self-check (smoke), không phải bộ test chính thức.** Các test này để
+> dev nhanh chóng kiểm chứng code mình sinh ra so với các BDD scenario. Đây là một
+> self-check của dev, **không** phải bộ test authoritative của QC/dev-team (cái đó có
+> flow riêng, implement ở nơi khác). Kết quả hiện lên dashboard Living Docs như một tín hiệu
+> **dev self-test** để QC thấy dev đã tự chạy check của mình.
 
 ## Gate
 {{include:steps/gate.md}}
 
-*Note: For this command, the target in Step 1 is a UC-ID or `.feature` file path. Find the feature file at `{paths.specs_dir}/{domain}/*/bdd/**/{UC-ID}-*.feature` (glob match across PRDs — filename includes slug suffix) and the implementation files tagged `@trace.implements={UC-ID}`.*
+*Lưu ý: Với lệnh này, target ở Bước 1 là một UC-ID hoặc path file `.feature`. Tìm file feature tại `{paths.specs_dir}/{domain}/*/bdd/**/{UC-ID}-*.feature` (glob khớp xuyên các PRD — filename gồm hậu tố slug) và các file implementation gắn tag `@trace.implements={UC-ID}`.*
 
 ## Context
 {{include:steps/context-loader.md}}
@@ -18,16 +18,16 @@
 
 ## Service Detection
 
-Read `@trace.service` and `@trace.module` from the feature file header.
+Đọc `@trace.service` và `@trace.module` từ header file feature.
 
-| Condition | Action |
+| Điều kiện | Hành động |
 |---|---|
-| `@trace.module` present | Use as `active_module` |
-| `@trace.module` absent | Use `tech_stack.module` from project-context.yaml |
-| `@trace.service` present | Store as `active_service` |
-| `@trace.service` absent | Use `{UC-ID}` domain as fallback |
+| `@trace.module` có mặt | Dùng làm `active_module` |
+| `@trace.module` vắng | Dùng `tech_stack.module` từ project-context.yaml |
+| `@trace.service` có mặt | Lưu làm `active_service` |
+| `@trace.service` vắng | Dùng domain của `{UC-ID}` làm fallback |
 
-**Platform type classification:**
+**Phân loại platform type:**
 
 | Platform | Modules |
 |---|---|
@@ -39,28 +39,28 @@ Read `@trace.service` and `@trace.module` from the feature file header.
 
 ## CHECKPOINT — Test Plan
 
-Before generating, scan the feature file for scenarios and the implementation files for classes/functions. Display:
+Trước khi sinh, quét file feature tìm scenario và các file implementation tìm class/function. Hiện:
 
 ```
 Test Plan — {UC-ID} ({active_module})
 ──────────────────────────────────────
 Platform   : {backend | web-frontend | mobile}
-Scenarios  : {N} scenarios from .feature file
-Impl files : {list of files tagged @trace.implements={UC-ID}}
+Scenarios  : {N} scenario từ file .feature
+Impl files : {danh sách file gắn tag @trace.implements={UC-ID}}
 
-Tests to generate:
-  {platform-specific list — see templates below}
+Test cần sinh:
+  {danh sách riêng theo platform — xem template bên dưới}
 
 Proceed? (Y/N)
 ```
 
-Wait for explicit "Y" before generating.
+Chờ "Y" rõ ràng trước khi sinh.
 
 ---
 
 ## Generate
 
-### If `platform_type = backend`
+### Nếu `platform_type = backend`
 
 #### java-spring
 
@@ -97,10 +97,10 @@ class {Resource}ControllerTest {
 ```
 
 Rules:
-- Unit tests: mock at Repository layer, test Service logic
-- Integration tests: mock at Facade/Service layer, test HTTP contract only
-- Never mock the class under test
-- Follow naming: `methodName_whenCondition_shouldOutcome` (from CLAUDE.md §6)
+- Unit test: mock ở layer Repository, test logic Service
+- Integration test: mock ở layer Facade/Service, chỉ test HTTP contract
+- Không bao giờ mock class đang được test
+- Theo naming: `methodName_whenCondition_shouldOutcome` (từ CLAUDE.md §6)
 
 #### golang
 
@@ -180,9 +180,9 @@ class {Resource}ControllerTest extends TestCase {
 
 #### context-engineering
 
-Check `tech_stack.language` from project-context.yaml to select the correct test syntax:
+Kiểm tra `tech_stack.language` từ project-context.yaml để chọn đúng cú pháp test:
 
-**If language = Python** (default):
+**Nếu language = Python** (mặc định):
 
 ```python
 # @trace.verifies={UC-ID}
@@ -221,7 +221,7 @@ class Test{Resource}Prompt:
             {function}(input=None)
 ```
 
-**If language = TypeScript / JavaScript** (Node.js LangChain.js, etc.):
+**Nếu language = TypeScript / JavaScript** (Node.js LangChain.js, v.v.):
 
 ```typescript
 // @trace.verifies={UC-ID}
@@ -244,17 +244,17 @@ describe('{Resource}Prompt', () => {
 })
 ```
 
-**If language = Java** (LangChain4j, etc.): use JUnit 5 + Mockito, same patterns as java-spring unit tests above — mock the `ChatLanguageModel` interface.
+**Nếu language = Java** (LangChain4j, v.v.): dùng JUnit 5 + Mockito, cùng pattern như unit test java-spring ở trên — mock interface `ChatLanguageModel`.
 
 Rules:
-- Mock the LLM client at the boundary — never call real LLM in unit tests
-- Validate input schema and output schema separately
-- Each scenario in `.feature` maps to one test function
-- Use parameterized tests for multiple input variants
+- Mock LLM client ở boundary — không bao giờ gọi LLM thật trong unit test
+- Validate input schema và output schema riêng biệt
+- Mỗi scenario trong `.feature` map sang một test function
+- Dùng parameterized test cho nhiều biến thể input
 
 ---
 
-### If `platform_type = web-frontend`
+### Nếu `platform_type = web-frontend`
 
 #### react / nextjs / vue / nuxt / angular
 
@@ -292,15 +292,15 @@ test('{scenario from .feature}', async ({ page }) => {
 ```
 
 Rules:
-- One component test file per component involved in the UC
-- One E2E test file per UC covering happy path + key error scenarios
-- Mock API calls at the network layer (MSW or cy.intercept), not at component props
-- Use accessible queries (`getByRole`, `getByLabelText`) — avoid `getByTestId` unless necessary
-- Each test maps to exactly one scenario in the `.feature` file
+- Một file component test cho mỗi component liên quan tới UC
+- Một file E2E test cho mỗi UC, phủ happy path + các error scenario chính
+- Mock API call ở network layer (MSW hoặc cy.intercept), không phải ở component props
+- Dùng accessible query (`getByRole`, `getByLabelText`) — tránh `getByTestId` trừ khi cần
+- Mỗi test map đúng một scenario trong file `.feature`
 
 ---
 
-### If `platform_type = mobile`
+### Nếu `platform_type = mobile`
 
 #### flutter
 
@@ -436,37 +436,37 @@ class {Feature}ScreenTest {
 
 ## Checklist
 
-**All platforms:**
-- [ ] `@trace.verifies` on every test class / test group
-- [ ] `@trace.service` on every test class / test group
-- [ ] Every scenario in `.feature` file has ≥ 1 corresponding test
-- [ ] Happy path covered
-- [ ] Key error / edge case scenarios covered
+**Mọi platform:**
+- [ ] `@trace.verifies` trên mỗi test class / test group
+- [ ] `@trace.service` trên mỗi test class / test group
+- [ ] Mỗi scenario trong file `.feature` có ≥ 1 test tương ứng
+- [ ] Phủ happy path
+- [ ] Phủ các scenario error / edge case chính
 
-**Backend only:**
-- [ ] Correct layer mocked (Repository in unit tests, Facade/Service in controller tests)
-- [ ] No real DB calls in unit tests
-- [ ] Test naming follows `methodName_whenCondition_shouldOutcome` (CLAUDE.md §6)
+**Chỉ backend:**
+- [ ] Mock đúng layer (Repository trong unit test, Facade/Service trong controller test)
+- [ ] Không gọi DB thật trong unit test
+- [ ] Test naming theo `methodName_whenCondition_shouldOutcome` (CLAUDE.md §6)
 
-**Frontend / Mobile only:**
-- [ ] No hardcoded delays (`sleep`, `setTimeout`) in tests — use `waitFor` / `pumpAndSettle`
-- [ ] Accessible queries used (role, label) not implementation-specific selectors
-- [ ] API calls mocked at network layer, not at component level
+**Chỉ Frontend / Mobile:**
+- [ ] Không hardcode delay (`sleep`, `setTimeout`) trong test — dùng `waitFor` / `pumpAndSettle`
+- [ ] Dùng accessible query (role, label) không phải selector phụ thuộc implementation
+- [ ] Mock API call ở network layer, không phải ở component level
 
 ---
 
 ## Write Trace State
 
-After generating all test files, update `{paths.trace_dir}/{domain}/{prd-slug}/{UC-ID}.tsv` — for each scenario, find the existing row by `sc_id` and update:
+Sau khi sinh tất cả file test, cập nhật `{paths.trace_dir}/{domain}/{prd-slug}/{UC-ID}.tsv` — với mỗi scenario, tìm row có sẵn theo `sc_id` và cập nhật:
 
-| Column | Value |
+| Cột | Giá trị |
 |--------|-------|
-| `test_count` | number of test methods covering this SC |
-| `test_classes` | comma-separated test class / describe-block names |
-| `dev_selftest` | `not_run` (tests now exist but have not been executed — `/dev-run-test` sets pass/fail) |
-| `last_updated` | today `YYYY-MM-DD` |
+| `test_count` | số test method phủ SC này |
+| `test_classes` | tên test class / describe-block, ngăn cách bởi dấu phẩy |
+| `dev_selftest` | `not_run` (test giờ đã tồn tại nhưng chưa chạy — `/dev-run-test` set pass/fail) |
+| `last_updated` | hôm nay `YYYY-MM-DD` |
 
-Leave all other columns unchanged (including `dev_selftest_at`, which `/dev-run-test` owns, and `qc_status`/`qc_run_at`, which `/qc-run-test` owns).
+Giữ nguyên mọi cột khác (gồm `dev_selftest_at`, do `/dev-run-test` sở hữu, và `qc_status`/`qc_run_at`, do `/qc-run-test` sở hữu).
 
 ---
 
@@ -480,11 +480,11 @@ Leave all other columns unchanged (including `dev_selftest_at`, which `/dev-run-
 {{include:steps/report-footer.md}}
 
 ```
-/dev-gen-test Complete — {UC-ID} ({active_module})
+/dev-gen-test Hoàn tất — {UC-ID} ({active_module})
   ✅ {TestClass1} ({N} tests)
   ✅ {TestClass2} ({N} tests)
 Trace: {paths.trace_dir}/{domain}/{prd-slug}/{UC-ID}.tsv updated
 Next: /dev-run-test {UC-ID}
 
-📊 Living Docs: run /validate-traces (or /sync) to push this trace to the spec-module dashboard.
+📊 Living Docs: chạy /validate-traces (hoặc /sync) để push trace này lên dashboard spec-module.
 ```