mcpbeat Sign in

Nw Test Organization Conventions Agent Skill

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

2k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
588
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/nWave-ai/nWave --skill nw-test-organization-conventions

The instruction itself

11 sections, as written by the author

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) |

Other skills for the same job

different authors, same section of the catalogue
Workflow Patterns
by ComeOnOliver
×2

Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.

6k tokens
Iso Standards Readiness
by K-Dense-AI
×1

Prepares and structurally reviews readiness evidence for ISO management-system and laboratory-competence standards - ISO 13485 medical device QMS, ISO 14971 device risk management, ISO/IEC 17025 testing and calibration laboratories, and ISO 15189 medical laboratories. Use when organizing declared scope, controlled documents, risk-management files, scope of accreditation, traceability, CAPA, external-provider controls, or bounded local evidence manifests, and when separating ISO certification from laboratory accreditation, FDA QMSR inspection, CLIA certification, MDSAP, and EU MDR/IVDR evidence boundaries. Not for legal applicability, compliance, certification, or accreditation decisions; contains no clause text.

67k tokens scripts
Statistical Power
by K-Dense-AI
×1

Sample-size and statistical power calculations for planning studies. Use whenever someone asks "how many subjects/samples/replicates do I need", wants an a priori power analysis, a minimum detectable effect (MDE), a power curve, or needs to justify a sample size for a grant, IRB protocol, or pre-registration. Covers closed-form power for t-tests, ANOVA, proportions, correlations, chi-square, and regression, plus simulation-based (Monte Carlo) power for designs with no formula — logistic/Poisson regression, mixed models, cluster-randomized trials, survival, and interactions. Use this skill even when the request only mentions an effect size, alpha, or "80% power" without saying "power analysis" explicitly. For laying out the study (randomization, blocking, factorial/DOE, crossover, sequential designs) use experimental-design; for analyzing data already collected and reporting it use statistical-analysis.

13k tokens scripts
General Figure Guide
by BioTender-max
×1

Universal QA checklist for generated scientific plots: overlapping labels, clipped text, missing axes/legends, overcrowded data, and cross-journal resolution/format guidance.

2k tokens
Nerdzao Elite
by ComeOnOliver
×1

Senior Elite Software Engineer (15+) and Senior Product Designer. Full workflow with planning, architecture, TDD, clean code, and pixel-perfect UX validation.

3k tokens
Pinchbench
by ComeOnOliver
×1

Run PinchBench benchmarks to evaluate OpenClaw agent performance across real-world tasks. Use when testing model capabilities, comparing models, submitting benchmark results to the leaderboard, or checking how well your OpenClaw setup handles calendar, email, research, coding, and multi-step workflows.

2096k tokens scripts
Workflow Patterns
by ComeOnOliver
×1

Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.

6k tokens
Powertoys Verification
by microsoft
vendor

Verify PowerToys behavior end-to-end with the winapp CLI across two scenarios: (A) a module's release checklist against the installed build; (B) PR validation — derive each PR's checklist from its description + diff, then drive it against the installed build (a merged/shipped PR, or a whole release/hotfix set) or by building + sideloading the module when the PR isn't in the build yet (unmerged or not-yet-released). Drive each item via UIA invoke / Named Events / settings.json edits / clipboard / GPO / SendInput, and emit a structured PASS / FAIL / BLOCKED verdict per item with evidence (FAIL distinguishes product defects from stale/ambiguous checklist items). Use when asked to verify a module checklist, validate a PR, sign off a release/hotfix's PRs, or QA installed/sideloaded PowerToys bits. Combines generic winapp ui mechanics (references/winapp-ui-testing.md) with PT-specific recipes, per-scenario playbooks (references/scenarios/), and the helper .ps1 files shipped with this skill.

86k tokens scripts

How to use it

Copy the folder

Take nwave-ai/nw-test-organization-conventions from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.