Imported from kainos-academy-2026/team4-frontend (.github/skills/test-cases/SKILL.md). Install upstream with npx skills add kainos-academy-2026/team4-frontend --skill test-cases. Copyright stays with the author.

Test Plan CSV Generator

Overview

This skill generates comprehensive test plans in CSV format for team4-frontend features. The project uses Vitest for automated tests, Supertest for HTTP integration coverage, TypeScript for type safety, and follows an Express plus Nunjucks layering of route -> controller -> service -> mapper/model -> view.

Testing Philosophy

• Coverage Target: Aim for broad, meaningful coverage of repo behavior where feasible.
• Test Comprehensiveness: Generate a varied set of cases that reflect real user flows, rendering contracts, data mapping, and error handling.
• Output Format: CSV table for easy import to test management tools.
• Framework: Vitest with TypeScript support; use Supertest when route-level HTTP assertions are appropriate.
• Organization: Mirror source concerns under /test, matching controllers, services, mappers, routes, views, and public asset behavior.

Repo Context

• App type: Node 22 Express server rendering Nunjucks templates and serving static assets from public/ or dist/public/.
• Important source areas: src/controllers/, src/services/, src/mappers/, src/models/, src/routes/, src/views/, src/config/, src/mocks/.
• Important test areas: test/controllers/, test/services/, test/mappers/, test/routes/, test/views/, plus integration and asset-focused tests in test/*.test.ts.
• Relevant app behaviors: home page rendering, login page/demo auth behavior, job role list/detail flows, public asset serving, public path resolution, and fallback mock handling.

Test Suite Types

• Sanity: Focused verification of the changed route, view, service, mapper, or asset path to confirm the build is stable enough for deeper testing.
• Smoke: Minimal critical-path checks that validate app startup and high-risk user-facing flows such as home page rendering, login page rendering, and job role access.
• Feature: Focused coverage for one feature boundary and directly related dependencies, such as job roles or login flow.
• Full Regression: Broad repo-wide coverage including happy path, negative, edge, validation, rendering, and error handling behavior.

When generating test cases, always align depth and breadth with the selected suite type:

• Sanity: small targeted set for the recently changed slice and immediate defect-prone paths.
• Smoke: small high-value set only.
• Feature: comprehensive for the selected feature boundary.
• Full Regression: comprehensive across the requested scope or entire codebase.

Output Format

All test plans are generated as CSV tables with the following columns:

• ID: Unique test case identifier (TC-001, TC-002, etc.)
• Title: Descriptive test case name
• Test Type: Category of the test (Happy Path, Unhappy Path, Data Validation, Edge Case, Authorization & Security, etc.)
• Test Suite Type: Suite classification for execution strategy (Sanity, Smoke, Feature, Full Regression)
• Preconditions: Setup requirements before test execution
• Test Steps: Sequential steps to execute the test
• Expected Results: What should happen when test passes
• Actual Results: To be filled during test execution
• Test Data: Input values, rendered state, flags, mocks, or configuration used

Input Section

Function Name:

[Enter the function, route, template, or feature to test]
Search the relevant `src/` and `test/` areas to identify existing coverage and missing cases.
Prefer the nearest owning surface: route, controller, service, mapper, model, template, or public asset behavior.

Suite Type:

• Sanity
• Smoke
• Feature
• Full Regression

Split Output Into Categories:

• Yes
• No

If the user has not specified split preference, ask before generating:

• "Do you want the test cases split into separate category files (for example job-roles, login, views, or static-assets), or kept in one combined CSV?"

If the user has not specified suite type, ask before generating:

• "Which suite type do you want: sanity, smoke, feature, or full regression?"

File Location:

[Enter the file path where the behavior is controlled]
Explore repo structure including:
- src/controllers/ - HTTP request handlers that prepare view models
- src/services/ - Business logic and API/fallback orchestration
- src/mappers/ - API-to-model transformations
- src/models/ - Domain shapes and view-model contracts
- src/routes/ - Route registration and request wiring
- src/views/ - Nunjucks templates and rendering contracts
- src/config/ - Runtime configuration such as API client and demo auth flags
- src/mocks/ - Fallback mock data used when configured
- public/ - Static assets, client-side scripts, and branding styles

Function Type:

• Controller Method (handles HTTP requests and prepares render data)
• Service Method (business logic or API/fallback behavior)
• Mapper (data transformation)
• Route Module (routing and wiring)
• View Template Contract (rendered HTML behavior)
• Static Asset / Client Script Behavior
• Utility/Helper Function

Description:

[Brief description of what the function or feature does and where it sits in the route -> controller -> service -> mapper/model -> view flow]

Parameters:

[List each parameter, request input, template variable, config flag, or mock input with type and description]

Return Type:

[Specify the return type, rendered output, HTTP response, or side effect with description]

CSV Output Format

Generate test cases using this exact CSV format:

ID,Title,Test Type,Test Suite Type,Preconditions,Test Steps,Expected Results,Actual Results,Test Data
TC-001,Test name,Happy Path,Smoke,Prerequisites,Step 1; Step 2; Step 3,Expected outcome,,Input: value1; Mock: value2
TC-002,Test name,Unhappy Path,Full Regression,Prerequisites,Step 1; Step 2; Step 3,Expected outcome,,Input: value1; Mock: value2

CSV Guidelines:

• Use semicolons (;) to separate multiple items within a single field.
• Wrap fields containing commas in quotes ("field with, comma").
• ID format: TC-### (TC-001, TC-002, etc.).
• Test Type values: Happy Path, Unhappy Path, Data Validation, Edge Case, Authorization & Security, Error Handling.
• Test Suite Type values: Sanity, Smoke, Feature, Full Regression.
• Test Steps should be numbered and sequential.
• Keep Expected Results concise but complete.
• Leave Actual Results empty unless the user explicitly asks to populate execution outcomes.
• Include all relevant test data such as inputs, mocks, flags, expected markup fragments, or API responses.
• Record technique traceability only inside the Test Data field using Technique: <name>.

CSV Schema Safety Guardrails (Mandatory)

The output must always remain valid 9-column CSV with this exact header:

ID,Title,Test Type,Test Suite Type,Preconditions,Test Steps,Expected Results,Actual Results,Test Data

Hard constraints:

• Never append free text after the 9th column.
• Never add an extra Technique column.
• Never modify, reorder, or rename header columns.
• If adding metadata (for example technique), include it inside Test Data only.
• Keep Actual Results empty unless explicitly asked to populate execution outcomes.

Valid technique placement example:

TC-001,Job role list renders open roles,Happy Path,Smoke,App is configured with available job role data,1. Start the app; 2. Request GET /job-roles; 3. Verify rendered list,Returns 200; Returns HTML containing only open job roles,,"Input: GET /job-roles; Expected markup: job role cards; Technique: Use Case Testing"

Invalid patterns (forbidden):

• ...,"Input: ..."; Technique: Use Case Testing (text outside the 9th field)
• ...,Actual Results,Test Data,Technique (extra column)
• Any row with more or fewer than 9 CSV columns

Post-edit validation (required before finalizing):

• Confirm header exactly matches the canonical 9-column header.
• Confirm every data row parses to exactly 9 columns.
• Confirm all Technique: tags appear only within Test Data.
• Confirm split files and consolidated file use identical schema.

When split output is selected:

• Keep the same CSV schema in every file.
• Keep IDs globally unique across files where possible.
• Use clear file naming based on category, for example job-roles-test-cases.csv, login-test-cases.csv, views-test-cases.csv, or static-assets-test-cases.csv.

Test Case Categories to Cover

Happy Path (Success Cases):

• Normal execution with valid inputs.
• Common user journeys such as home page render, login page render, and job role list/detail views.

Unhappy Path (Failure Cases):

• Upstream API failures or empty responses.
• Missing role IDs, not-found behavior, and invalid route inputs.
• Rendered error states and graceful failure handling.

Edge Cases & Boundaries:

• Empty, null, or undefined template data.
• Open versus closed job role status boundaries.
• Special characters, unicode, and date formatting boundaries.
• Missing assets or stale dist/public path conditions.

Error Handling:

• Invalid inputs and validation failures.
• API/client failures and fallback mock behavior.
• HTTP error responses (400, 404, 500) when applicable.
• Friendly user-facing failure states instead of thrown rendering failures.

Data Validation:

• Type mismatches across controller, service, mapper, and view boundaries.
• Required field presence in template context or mapped role data.
• Format validation for email fields, dates, and URLs when surfaced by the feature.
• Business rules such as open-role filtering and detail lookup behavior.

Authorization & Security:

• Demo-auth gating and login-state UI behavior where applicable.
• Public route behavior and safe handling of user-facing inputs.
• Static asset exposure limited to intended public files.
• Mark as Technique: N/A - no auth boundary in scope when a feature has no meaningful auth/security branch.

Test Design Techniques (Mandatory)

When generating test cases, explicitly apply the following techniques:

• Equivalence Partitioning
• Boundary Value Analysis
• Decision Tables
• Error Guessing
• Risk Based Testing
• Use Case Testing

How To Apply Per Technique

Equivalence Partitioning:

• Identify valid and invalid input classes for requests, template variables, mapped API payloads, config flags, and fallback data.
• Add representative tests for each partition rather than redundant values.

Boundary Value Analysis:

• Include min-1, min, min+1 and max-1, max, max+1 where numeric or list boundaries are defined.
• For string/date/template constraints, include empty, just-inside, and just-outside boundaries.

Decision Tables:

• For multi-condition logic such as fallback enabled + API availability + role status, derive combinations and expected outcomes.
• Cover each decision rule at least once with clear expected status, rendered state, or mapped output.

Error Guessing:

• Add tests for realistic mistakes and malformed inputs based on implementation patterns.
• Include missing route params, malformed API payloads, absent template fields, unexpected types, and null/undefined values.

Risk Based Testing:

• Prioritize high-impact and high-likelihood risks first, especially route availability, user-facing rendering, critical asset serving, and job-role listing/detail behavior.
• Mark highest-priority tests as Smoke where appropriate.

Use Case Testing:

• Derive end-to-end user journeys and alternate flows from feature behavior.
• Include successful primary flow and at least one alternative or failure flow per major use case.

Technique Coverage Rules

• For Feature and Full Regression suites: include at least one test case per listed technique.
• For Sanity suites: apply Risk Based Testing and Use Case Testing as mandatory; include Decision Tables where fallback/config branching is touched.
• For Smoke suites: apply Risk Based Testing and Use Case Testing as mandatory; include other techniques where practical.
• Record the applied technique in the Test Data field using Technique: <name> for traceability.
• If a technique is not applicable, state Technique: N/A - <reason> in at least one relevant row.

Test Plan Re-Evaluation Workflow

Use this step-by-step process whenever the codebase changes and test plans may be outdated.

Re-Evaluation Triggers

Re-evaluate test plans when any of the following occurs:

• A new route, controller, service, mapper, model, template, static asset, or config flag is added.
• Existing logic, rendering rules, demo-auth behavior, fallback behavior, or error handling changes.
• Public path resolution, asset copying, or API integration contracts change.
• A defect is found that indicates a missing or weak test case.

Step-By-Step Re-Evaluation Plan

1. Confirm scope and suite strategy.

• Ask whether the update is Sanity, Smoke, Feature, or Full Regression.
• Ask whether output should be split or consolidated.

2. Detect and map code changes.

• Compare changed files and identify impacted modules in src/, public/, and test/.
• Classify each impacted area by type: route, controller, service, mapper, model, template, config, mock data, static asset, or infrastructure.

3. Build an impact matrix.

• Map each code change to affected behaviors, inputs, outputs, rendering contracts, and risks.
• Mark risk level as High, Medium, or Low based on user impact, failure likelihood, and visibility.

4. Re-apply test design techniques.

• Re-run Equivalence Partitioning, Boundary Value Analysis, Decision Tables, Error Guessing, Risk Based Testing, and Use Case Testing against changed areas.
• Add new cases where coverage gaps are found.
• Retire or de-prioritize obsolete tests where behavior no longer exists.

5. Update CSV test plan rows.

• Preserve existing IDs where test intent is unchanged.
• Create new IDs only for net-new test intents.
• Update Title, Test Type, Test Suite Type, Preconditions, Test Steps, Expected Results, and Test Data as needed.
• Ensure Test Data includes Technique: <name> for each row.

6. Validate quality gates.

• Verify all changed logic paths are covered by at least one relevant test.
• Verify high-risk paths are represented in Sanity/Smoke or top-priority Feature coverage.
• Verify rendering, fallback, and validation changes include negative and boundary tests.

7. Validate organization and consistency.

• If split output is selected, ensure each file uses identical schema and clear category naming.
• Ensure IDs remain unique across generated files where possible.
• Ensure no duplicate rows with identical intent and steps.

8. Validate CSV structure and field integrity.

• Verify exact header match: ID,Title,Test Type,Test Suite Type,Preconditions,Test Steps,Expected Results,Actual Results,Test Data.
• Verify every row has exactly 9 columns when parsed as CSV.
• Verify Technique: appears only inside Test Data and nowhere else.

9. Produce re-evaluation summary.

• Provide a concise delta report with: added tests, updated tests, removed tests, and residual risks.
• Call out any assumptions or unknowns that may require user confirmation.

Re-Evaluation Output Checklist

Before finalizing updated test plans, confirm:

• Suite type and split preference were confirmed.
• Impacted modules were identified and mapped.
• All six design techniques were re-applied.
• High-risk changes received prioritized Sanity/Smoke coverage.
• CSV schema is valid and consistent in all output files.
• Every row parses to exactly 9 columns; no trailing out-of-column metadata exists.
• Summary of changes and residual risk is included.

Split Recommendation Guidance

When asking about splitting output, include this rationale in concise form:

• Improves ownership by allowing teams to own specific suites.
• Speeds targeted execution for impacted areas.
• Reduces triage time by grouping failures by domain.
• Lowers merge conflicts compared with one large CSV.
• Maintains scalability as new features are added.

If user selects split output, also ask for preferred categories if not obvious:

• "Which categories do you want (for example job-roles, login, views, static-assets, or infrastructure)?"

If user selects non-split output:

• Generate one consolidated CSV and include all selected coverage scope.

Example CSV Output

ID,Title,Test Type,Test Suite Type,Preconditions,Test Steps,Expected Results,Actual Results,Test Data
TC-001,Home page renders branded shell,Happy Path,Smoke,Application is running with views and public assets available,1. Send GET request to /; 2. Inspect the HTML response; 3. Verify branded header,Returns 200 OK; Returns HTML; Includes branding stylesheet and auth action link,,"Input: GET /; Expected: branded home markup; Technique: Use Case Testing"
TC-002,Job role list excludes closed roles from the rendered list,Unhappy Path,Feature,Job role service receives open and closed roles,1. Prepare role data containing open and closed statuses; 2. Render or request the job role list path; 3. Inspect the visible roles,Only open roles are shown in the list,,"Input: open and closed role fixtures; Expected: closed role excluded; Technique: Decision Tables"
TC-003,Job role service falls back to mock data when fallback mode is enabled,Happy Path,Feature,`USE_JOB_ROLE_FALLBACK_MOCK=true` or equivalent service setup is enabled,1. Enable fallback mode; 2. Execute the job role list flow; 3. Inspect the returned roles,Returns fallback open roles without calling the upstream API,,"Input: fallback role fixtures; Flag: USE_JOB_ROLE_FALLBACK_MOCK=true; Technique: Risk Based Testing"
TC-004,Login page renders the branded contract when demo auth is disabled,Data Validation,Full Regression,Views are available and demo auth state is known,1. Render or request /login; 2. Inspect the response body; 3. Verify required markup fragments,Returns the branded login page with email and password inputs and login error placeholder,,"Input: demoAuthEnabled=false; Expected markup: data-login-form and branding assets; Technique: Equivalence Partitioning"
TC-005,Missing job role ID returns friendly not-found behavior,Error Handling,Full Regression,Application is running and the requested role does not exist,1. Send GET request to the job role detail route with a missing ID; 2. Inspect status and body; 3. Verify the failure state,Returns the expected not-found or friendly failure response without crashing the render path,,"Input: nonexistent role id; Expected: friendly failure state; Technique: Error Guessing"
TC-006,Static branding assets are served from public paths,Happy Path,Sanity,Application is running with public assets available,1. Request /styles/branding.css; 2. Request /scripts/auth.js; 3. Request the logo image path,Each asset returns 200 and the correct content type,,"Input: GET /styles/branding.css; GET /scripts/auth.js; GET /images/kainoslogo.png; Technique: Boundary Value Analysis"