nw-test-organization-conventions

Test directory structure patterns by architecture style, language conventions, naming rules, and fixture placement. Decision tree for selecting test organization strategy.

322 stars

Best use case

nw-test-organization-conventions is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Test directory structure patterns by architecture style, language conventions, naming rules, and fixture placement. Decision tree for selecting test organization strategy.

Teams using nw-test-organization-conventions should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/nw-test-organization-conventions/SKILL.md --create-dirs "https://raw.githubusercontent.com/nWave-ai/nWave/main/nWave/skills/nw-test-organization-conventions/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/nw-test-organization-conventions/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How nw-test-organization-conventions Compares

Feature / Agentnw-test-organization-conventionsStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Test directory structure patterns by architecture style, language conventions, naming rules, and fixture placement. Decision tree for selecting test organization strategy.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

Related Guides

SKILL.md Source

# Test Organization Conventions

## Core Principle

Test directory structure encodes architectural boundaries. If a developer cannot infer the architecture from the test tree alone, the organization is wrong.

## Architecture-to-Organization Decision Tree

```
What is the project's architectural style?
|
+-- Hexagonal / Clean Architecture
|   --> Test-type-first: tests/{unit,integration,acceptance,e2e}/
|   --> Domain concepts nested within each type
|   --> Port contract tests in tests/integration/
|
+-- Vertical Slice
|   --> Co-located: features/{slice}/tests/
|   --> Cross-slice tests in top-level tests/cross_feature/
|
+-- Modular Monolith
|   --> Module-first: tests/modules/{module}/{unit,integration}/
|   --> Architecture tests per module (dependency rule enforcement)
|   --> Inter-module tests in tests/inter_module/
|
+-- Microservices
|   --> Per-service test tree: {service}/tests/{unit,integration,component,contract}/
|   --> Contract tests: consumer writes in own repo, provider verifies in own repo
|   --> Cross-service E2E in separate project: e2e-tests/
|
+-- Event-Driven
|   --> Test-type-first with event-specific categories
|   --> Unique: schema contract tests, idempotency tests, saga compensation tests
|
+-- CQRS
|   --> Command/Query split within each test type
|   --> Unique: projection tests (rebuild + idempotency)
|
+-- Layered (N-Tier)
|   --> Mirror source: tests mirror src layer hierarchy
|   --> Integration tests verify layer boundary contracts
|
+-- DDD (Tactical)
|   --> Bounded-context-first: tests/{context}/domain/aggregates/
|   --> Cross-context contract tests in tests/bounded_context_integration/
```

## Comparative Summary

| Architecture | Primary Axis | Secondary Axis | Unique Test Types | Co-located? |
|-------------|-------------|----------------|-------------------|-------------|
| Hexagonal | Test type | Domain concept | Port contract | No |
| Clean | Test type | Architecture ring | Gateway | No |
| Layered | Mirror source | Test type | Layer boundary | No (Java: yes) |
| Vertical Slice | Feature | Test type | Cross-slice | Yes |
| Modular Monolith | Module | Test type | Architecture, inter-module | No |
| Microservices | Per-service | Test type | Contract (Pact) | No |
| Event-Driven | Test type | Event flow role | Schema, idempotency, saga | No |
| CQRS | Command/Query | Test type | Projection | No |
| DDD | Bounded context | Building block | Aggregate, cross-context | No |

## Mirror vs. Feature vs. Hybrid

| Strategy | Best For | Strengths | Weaknesses |
|----------|----------|-----------|------------|
| Mirror source | Layered, Clean, Hexagonal | Predictable paths, IDE navigation, package-private access (Java) | Feature changes touch multiple dirs |
| Feature co-located | Vertical Slice, React | All feature code in one place, team ownership | Cross-feature tests homeless, hard to run by tier |
| Hybrid (recommended) | Most projects | Type-first for CI stages, feature-nested within | Slightly deeper nesting |

Hybrid pattern (type-first, then feature within):

```
tests/
  unit/
    features/
      order/test_create_order.py
      payment/test_process_payment.py
  integration/
    features/
      order/test_order_repository.py
  e2e/
    test_checkout_flow.py
```

## Language-Specific Conventions

| Language | File Convention | Discovery Rule | Co-located? |
|----------|---------------|----------------|-------------|
| Python (pytest) | `test_*.py` or `*_test.py` | Prefix/suffix match | Separate `tests/` (recommended) or inlined |
| TypeScript/JS (Jest) | `*.test.ts`, `*.spec.ts`, `__tests__/*.ts` | testMatch pattern | Either |
| Java (JUnit/Maven) | `*Test.java` in mirrored package | `src/test/java` mirrors `src/main/java` | Mirrored packages |
| Go | `*_test.go` in same directory | Language-enforced co-location | Always co-located |
| C# (xUnit/NUnit) | `*Tests.cs` in parallel project | Separate test project | Separate project |
| Rust | `#[cfg(test)] mod tests` inline + `tests/` | Inline for unit, `tests/` for integration | Unit: inline, Integration: separate |

### Python conftest.py Placement

Place `conftest.py` at the lowest directory where fixtures apply. Pytest discovers from outermost to innermost, enabling hierarchical fixture scoping:

```
tests/
  conftest.py              # Session fixtures: DB engine, app instance
  unit/
    conftest.py            # Unit-specific: auto-mock markers
  integration/
    conftest.py            # Integration: real DB fixtures
  acceptance/
    conftest.py            # Acceptance: feature file paths
```

### BDD Feature Files

```
tests/
  features/                # Gherkin .feature files by domain
    order/
      place_order.feature
    payment/
      process_payment.feature
  step_defs/               # Step implementations by domain concept
    conftest.py
    order_steps.py
    payment_steps.py
```

Organize step definitions by domain concept, not by feature file. Shared steps across features prevent duplication.

## Hexagonal Architecture Test Tiers

| Tier | Location | Tests | Adapters |
|------|----------|-------|----------|
| Unit | tests/unit/ | Domain model, value objects, service layer | None (pure) or mock driven ports |
| Integration | tests/integration/ | Individual adapters against real infra | Real infrastructure |
| Acceptance | tests/acceptance/ | Use cases through driving ports | In-memory adapters |
| E2E | tests/e2e/ | Full stack through HTTP/CLI | Real adapters |

Port contract tests: when multiple adapters implement one driven port, create shared contract test suite and run against each adapter.

```
tests/integration/
  test_repository_contract.py     # Abstract tests for RepositoryPort
  test_postgres_repository.py     # Runs contract against Postgres
  test_inmemory_repository.py     # Runs contract against in-memory
```

## Fixture Organization

| Scope | What | Placement |
|-------|------|-----------|
| Session | Expensive setup (DB engine, app) | Root conftest.py |
| Module | Schema creation, service containers | Directory conftest.py |
| Function | Data cleanup, test isolation | autouse=True in conftest.py |
| Shared across types | Factories, builders | tests/conftest.py or tests/fixtures/ |

## Anti-Patterns

| Anti-Pattern | Why It Fails | Fix |
|---|---|---|
| Flat tests/ with no structure | Cannot run by tier, no boundary visibility | Organize by primary axis of architecture |
| Mirroring hex layers in test tree | Couples tests to implementation structure | Organize by test type, not source structure |
| Acceptance tests alongside E2E | Acceptance should use in-memory adapters and run fast | Separate: acceptance/ (fast) vs e2e/ (slow) |
| Feature-coupled step definitions | Steps for login.feature only usable there | Organize steps by domain concept |
| Mixing test tiers in one directory | Cannot run unit-only in pre-commit | Separate directories per tier |
| Cross-module imports in tests | Violates module boundaries | Use inter-module tests with event bus |
| E2E inside single microservice | They span services by definition | Move to separate e2e-tests/ project |
| No contract tests between services | Mocks drift from reality | Consumer-driven contract tests (Pact) |

Related Skills

nw-test-refactoring-catalog

322
from nWave-ai/nWave

Detailed refactoring mechanics with step-by-step procedures, and test code smell catalog with detection patterns and before/after examples

nw-test-design-mandates

322
from nWave-ai/nWave

Four design mandates for acceptance tests - hexagonal boundary enforcement, business language abstraction, user journey completeness, walking skeleton strategy, and pure function extraction

nw-property-based-testing

322
from nWave-ai/nWave

Property-based testing strategies, mutation testing, shrinking, and combined PBT+mutation workflow for test quality validation

nw-mutation-test

322
from nWave-ai/nWave

Runs feature-scoped mutation testing to validate test suite quality. Use after implementation to verify tests catch real bugs (kill rate >= 80%).

nw-hexagonal-testing

322
from nWave-ai/nWave

5-layer agent output validation, I/O contract specification, vertical slice development, and test doubles policy with per-layer examples

nw-agent-testing

322
from nWave-ai/nWave

5-layer testing approach for agent validation including adversarial testing, security validation, and prompt injection resistance

nw-ux-web-patterns

322
from nWave-ai/nWave

Web UI design patterns for product owners. Load when designing web application interfaces, writing web-specific acceptance criteria, or evaluating responsive designs.

nw-ux-tui-patterns

322
from nWave-ai/nWave

Terminal UI and CLI design patterns for product owners. Load when designing command-line tools, interactive terminal applications, or writing CLI-specific acceptance criteria.

nw-ux-principles

322
from nWave-ai/nWave

Core UX principles for product owners. Load when evaluating interface designs, writing acceptance criteria with UX requirements, or reviewing wireframes and mockups.

nw-ux-emotional-design

322
from nWave-ai/nWave

Emotional design and delight patterns for product owners. Load when designing onboarding flows, empty states, first-run experiences, or evaluating the emotional quality of an interface.

nw-ux-desktop-patterns

322
from nWave-ai/nWave

Desktop application UI patterns for product owners. Load when designing native or cross-platform desktop applications, writing desktop-specific acceptance criteria, or evaluating panel layouts and keyboard workflows.

nw-user-story-mapping

322
from nWave-ai/nWave

User story mapping for backlog management and outcome-based prioritization. Load during Phase 2.5 (User Story Mapping) to produce story-map.md and prioritization.md.