Skip to main content

testing-guide

Testing pyramid and test writing standards for UT/IT/ST/E2E. Supports ISTQB and Industry Pyramid frameworks. Use when: writing tests, discussing test coverage, test strategy, or test naming. Not for: driving a Red-Green-Refactor cycle — use /tdd; measuring achieved coverage — use /coverage. Keywords: test, unit, integration, e2e, coverage, mock, ISTQB, SIT.

Source facts

Repository
AsiaOstrich/universal-dev-standards
Last source activity
August 17, 2026 at 06:20
Detected SKILL.md language
English
Stars
76
Forks
13

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
4 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
testing-guide
scope
universal
description
Testing pyramid and test writing standards for UT/IT/ST/E2E. Supports ISTQB and Industry Pyramid frameworks. Use when: writing tests, discussing test coverage, test strategy, or test naming. Not for: driving a Red-Green-Refactor cycle — use /tdd; measuring achieved coverage — use /coverage. Keywords: test, unit, integration, e2e, coverage, mock, ISTQB, SIT.
# Testing Guide > **Language**: English | [繁體中文](../../locales/zh-TW/skills/testing-guide/SKILL.md) **Version**: 1.2.0 **Last Updated**: 2026-01-29 **Applicability**: Claude Code Skills --- ## Purpose This skill provides testing pyramid standards and best practices for systematic testing, supporting both ISTQB and Industry Pyramid frameworks. ## Testing Skills Navigator | 測試技能導航 UDS provides 6 testing-related skills. Use this decision tree to find the right one: ``` What do you want to do? | 你想做什麼? ├── Measure code coverage (lines/branches/functions) → /coverage ├── Track which requirements have tests (AC traceability) → /ac-coverage ├── Develop with Test-Driven Development (Red-Green-Refactor) → /tdd ├── Write BDD scenarios (Given-When-Then) → /bdd ├── Define acceptance tests with stakeholders → /atdd └── Learn testing standards and best practices → /testing (this skill) ``` | Skill | Focus | 焦點 | |-------|-------|------| | `/testing` | Standards and best practices reference | 測試標準與最佳實踐參考 | | `/coverage` | Code-level coverage analysis | 程式碼層級覆蓋率分析 | | `/ac-coverage` | Requirement-level AC traceability | 需求層級 AC 可追蹤性 | | `/tdd` | Red-Green-Refactor development cycle | 紅-綠-重構開發循環 | | `/bdd` | Behavior scenarios with Given-When-Then | Given-When-Then 行為場景 | | `/atdd` | Acceptance criteria with stakeholders | 與利害關係人定義驗收條件 | ## Framework Selection | Framework | Levels | Best For | |-----------|--------|----------| | **ISTQB** | UT → IT/SIT → ST → AT/UAT | Enterprise, compliance, formal QA | | **Industry Pyramid** | UT (70%) → IT (20%) → E2E (10%) | Agile, DevOps, CI/CD | **Note on Integration Testing abbreviation:** - **IT** (Integration Testing): Agile/DevOps communities - **SIT** (System Integration Testing): Enterprise/ISTQB contexts - Both refer to the same testing level ## Quick Reference ### Testing Pyramid (Industry Standard) ``` ┌─────────┐ │ E2E │ ← 10% (Fewer, slower) ─┴─────────┴─ ┌─────────────┐ │ IT/SIT │ ← 20% (Integration) ─┴─────────────┴─ ┌─────────────────┐ │ UT │ ← 70% (Unit) └─────────────────┘ ``` ### Test Levels Overview | Level | Scope | Speed | Dependencies | |-------|-------|-------|-------------| | **UT** | Single function/class | < 100ms | Mocked | | **IT/SIT** | Component interaction | 1-10s | Real DB (containerized) | | **ST** | Full system (ISTQB) | Minutes | Production-like | | **E2E** | User journeys | 30s+ | Everything real | | **AT/UAT** | Business validation (ISTQB) | Varies | Everything real | ### Coverage Targets | Metric | Minimum | Recommended | |--------|---------|-------------| | Line | 70% | 85% | | Branch | 60% | 80% | | Function | 80% | 90% | ## Detailed Guidelines For complete standards, see: - [Testing Standards](../../core/testing-standards.md) - Actionable rules - [Testing Theory](./testing-theory.md) - Educational knowledge base - [Testing Pyramid](./testing-pyramid.md) - Detailed pyramid ratios - [Test Skeleton Templates](./test-skeleton-templates.md) - Multi-language skeletons for UT/IT/ST/Perf/Contract ### AI-Optimized Format (Token-Efficient) For AI assistants, use the YAML format files for reduced token usage: - Base standard: `ai/standards/testing.ai.yaml` - Framework options: - ISTQB Framework: `ai/options/testing/istqb-framework.ai.yaml` - Industry Pyramid: `ai/options/testing/industry-pyramid.ai.yaml` - Test level options: - Unit Testing: `ai/options/testing/unit-testing.ai.yaml` - Integration Testing: `ai/options/testing/integration-testing.ai.yaml` - System Testing: `ai/options/testing/system-testing.ai.yaml` - E2E Testing: `ai/options/testing/e2e-testing.ai.yaml` - Security Testing: `ai/options/testing/security-testing.ai.yaml` - Performance Testing: `ai/options/testing/performance-testing.ai.yaml` - Contract Testing: `ai/options/testing/contract-testing.ai.yaml` - Skeleton templates (all levels, multi-language): [test-skeleton-templates.md](./test-skeleton-templates.md) ## Naming Conventions ### File Naming ``` [ClassName]Tests.cs # C# [ClassName].test.ts # TypeScript [class_name]_test.py # Python [class_name]_test.go # Go ``` ### Method Naming ``` [MethodName]_[Scenario]_[ExpectedResult]() should_[behavior]_when_[condition]() test_[method]_[scenario]_[expected]() ``` ## Test Doubles | Type | Purpose | When to Use | |------|---------|-------------| | **Stub** | Returns predefined values | Fixed API responses | | **Mock** | Verifies interactions | Check method called | | **Fake** | Simplified implementation | In-memory database | | **Spy** | Records calls, delegates | Partial mocking | ### When to Use What - **UT**: Use mocks/stubs for all external deps - **IT**: Use fakes for DB, stubs for external APIs - **ST**: Real components, fake only external services - **E2E**: Real everything ## AAA Pattern ```typescript test('method_scenario_expected', () => { // Arrange - Setup test data const input = createTestInput(); const sut = new SystemUnderTest(); // Act - Execute behavior const result = sut.execute(input); // Assert - Verify result expect(result).toBe(expected); }); ``` ## FIRST Principles - **F**ast - Tests run quickly - **I**ndependent - Tests don't affect each other - **R**epeatable - Same result every time - **S**elf-validating - Clear pass/fail - **T**imely - Written with production code ## Anti-Patterns to Avoid - ❌ Test Interdependence (tests must run in order) - ❌ Flaky Tests (sometimes pass, sometimes fail) - ❌ Testing Implementation Details - ❌ Over-Mocking - ❌ Missing Assertions - ❌ Magic Numbers/Strings --- ## Testing Theory Essentials (YAML Compressed) ```yaml # === ISTQB FUNDAMENTALS === terminology: error: "Human mistake in thinking" defect: "Bug in code (caused by error)" failure: "System behaves incorrectly (caused by defect)" chain: "Error → Defect → Failure" oracle_problem: definition: "How do we know the expected result is correct?" approaches: - specification_oracle: "Compare against spec" - reference_oracle: "Compare against reference impl" - consistency_oracle: "Same input → same output" - heuristic_oracle: "Reasonable approximation" # === STATIC vs DYNAMIC === static_testing: definition: "Examine without executing" techniques: [reviews, walkthroughs, inspections, static_analysis] finds: "Defects before runtime" examples: [ESLint, SonarQube, code_review] dynamic_testing: definition: "Execute and observe behavior" techniques: [unit, integration, system, acceptance] finds: "Failures during execution" # === TEST DESIGN TECHNIQUES === black_box: equivalence_partitioning: principle: "Divide inputs into equivalent classes" example: "Age: [<0 invalid], [0-17 minor], [18-64 adult], [65+ senior]" boundary_value: principle: "Test at boundaries of partitions" example: "Age: test -1, 0, 17, 18, 64, 65" decision_table: principle: "Combinations of conditions → actions" use: "Complex business rules" state_transition: principle: "Valid sequences of states" use: "Workflow, state machines" white_box: statement_coverage: "Every statement executed once" branch_coverage: "Every decision branch taken" condition_coverage: "Every condition T/F" path_coverage: "Every possible path (often impractical)" # === RISK-BASED TESTING === risk_assessment: likelihood: "How likely to fail?" impact: "How bad if fails?" priority: "likelihood × impact" risk_matrix: high_high: "Test extensively, first priority" high_low: "Good coverage" low_high: "Good coverage" low_low: "Basic coverage" # === DEFECT MANAGEMENT === defect_lifecycle: states: [new, assigned, in_progress, fixed, verified, closed] reopen_trigger: "Verification fails" severity_vs_priority: severity: "Technical impact (critical/major/minor/trivial)" priority: "Business urgency (high/medium/low)" example: "Typo on login page: low severity, high priority (brand)" # === TEST ENVIRONMENT === isolation_levels: unit: "In-memory, mocked deps" integration: "Containerized DB (Docker)" staging: "Production-like, isolated" production: "Real, feature flags for testing" test_data_strategies: fixtures: "Static predefined data" factories: "Dynamic generation (faker)" snapshots: "Sanitized production copy" synthetic: "Algorithm-generated edge cases" ``` --- ## Configuration Detection This skill supports project-specific configuration. ### Detection Order 1. Check `CONTRIBUTING.md` for "Disabled Skills" section - If this skill is listed, it is disabled for this project 2. Check `CONTRIBUTING.md` for "Testing Standards" section 3. If not found, **default to standard coverage targets** ### First-Time Setup If no configuration found and context is unclear: 1. Ask the user: "This project hasn't configured testing standards. Would you like to customize coverage targets?" 2. After user selection, suggest documenting in `CONTRIBUTING.md`: ```markdown ## Testing Standards ### Coverage Targets | Metric | Target | |--------|--------| | Line | 80% | | Branch | 70% | | Function | 85% | ``` ### Configuration Example In project's `CONTRIBUTING.md`: ```markdown ## Testing Standards ### Coverage Targets | Metric | Target | |--------|--------| | Line | 80% | | Branch | 70% | | Function | 85% | ### Testing Framework - Unit Tests: Jest - Integration Tests: Supertest - E2E Tests: Playwright ``` --- ## Next Steps Guidance | 下一步引導 After `/testing` completes, the AI assistant should suggest: > **測試標準與最佳實踐已掌握。建議下一步 / Testing standards and best practices understood. Suggested next steps:** > - 執行 `/tdd` 開始測試驅動開發(紅-綠-重構循環) ⭐ **Recommended / 推薦** — 將測試知識立即轉化為實踐 / Turn testing knowledge into practice immediately > - 執行 `/coverage` 分析目前程式碼覆蓋率 — 找出測試缺口 / Identify testing gaps > - 執行 `/bdd` 撰寫行為驅動的 Given-When-Then 場景 — 從使用者角度定義測試 / Define tests from user perspective --- ## Related Standards - [Testing Standards](../../core/testing-standards.md) - Actionable rules - [Testing Theory](./testing-theory.md) - Educational knowledge base - [Code Review Checklist](../../core/code-review-checklist.md) --- ## Version History | Version | Date | Changes | |---------|------|---------| | 1.2.0 | 2026-01-29 | Added links to new testing-theory.md knowledge base | | 1.1.0 | 2025-12-29 | Added Testing Theory Essentials YAML section | | 1.0.0 | 2025-12-24 | Initial: Standard sections (Purpose, Related Standards, Version History, License) | --- ## License This skill is released under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). **Source**: [universal-dev-standards](https://github.com/AsiaOstrich/universal-dev-standards)
View on GitHub