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.

소스 정보

저장소
AsiaOstrich/universal-dev-standards
최근 소스 활동
2026년 8월 17일 06:20
감지된 SKILL.md 언어
영어
스타
80
포크
14

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
4 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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)
GitHub에서 보기