skills.rest
nakamori-naoya
nakamori-naoyaCOMMUNITY
Explore all skills by this author →
GitHub

test-domain-model

Writes Go domain model tests from BDD mapping tables in domain-model documents.

Updated Sep 14, 2026
Search Tags:#specification#domain-driven design#go#testify#bdd#table-driven tests#aggregate testing
One-click install
npx skills add https://github.com/nakamori-naoya/go-convention-plugins --skill test-domain-model-nakamori-naoya
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-domain-model
Source: https://github.com/nakamori-naoya/go-convention-plugins/tree/main/plugins/go-convention/skills/test-domain-model
Command: npx skills add https://github.com/nakamori-naoya/go-convention-plugins --skill test-domain-model-nakamori-naoya

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Writing tests for Go domain aggregates, entities, and value objects often drifts away from the specification: cases get invented, BDD scenarios get lost, and coverage against the domain-model document is unverifiable. This Skill derives every test case directly from the document's BDD mapping table so each scenario lands in exactly one test function and every document ID is accounted for. ## Core Features & Use Cases - Document-driven test allocation: Maps each BDD scenario to a test function via the document's element x operation table (generation functions, state-type methods, narrowing functions, value object operations). - Deterministic table shape: Given fields mirror Restore*/New* argument names, Then fields use wantNext/wantEvent/wantErr/wantOK, with sentinel errors and testify require/assert conventions. - Machine-checked coverage: Ships scripts/check-bdd-coverage.py to verify every BDD ID appears either in a test case id or in a reasoned trailing omission comment. - Use Case: Given a domain-model document for a room reservation aggregate, generate reservation_test.go where BDD-001 through BDD-024 are each assigned to TestHold, TestTentative_Confirm, TestAsTentative, or explicitly listed as untested with reasons. ## Quick Start Write the tests for this aggregate from the BDD mapping table in this domain-model document.

Frequently Asked Questions about test-domain-model

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write Go domain model tests from a BDD specification?▼

Assign each BDD scenario to one test function based on the document's element x operation mapping table, then copy the scenario's ID, heading, and gherkin block into id, name, and description fields. Given values become Restore*/New* arguments and Then values become wantNext, wantEvent, or wantErr sentinel assertions.

What should Go aggregate tests cover and exclude?▼

Cover generation preconditions, transition sentinels, emitted event values, narrowing function rejections, and value object boundaries. Exclude getter-only checks, persistence round-trips, other aggregates' decisions, usecase orchestration, concurrency, and logging, which belong to other layers.

How do I verify BDD coverage in Go test files?▼

Run the included check-bdd-coverage.py script with the domain-rule document and test directory as arguments. It confirms every BDD ID appears exactly once in either a test case id field or a reasoned trailing omission comment, exiting with code 1 on violations.

Can I write domain tests before the implementation exists?▼

Yes, test-first is a supported scenario. Derive names and signatures from the document's elements, operations, and rejection reasons using the implementation conventions (New*/Restore*, state-type methods, As*, Err*), and treat compile errors from undefined symbols as the expected red state.

Why should domain tests avoid mocks and databases?▼

Domain tests verify decisions using only in-memory values, so inputs are Restore*/New* arguments and outputs are return values like Next, Event, error, or bool. Persistence round-trips, DB constraints, and concurrency are handled by the persistence layer's own tests.

Related Skills

Explore More Software Engineering Skills→
wizelinewizeline

unit-test-shifting-left-from-requirements

Generate unit test skeletons and BDD scenarios from requirements.

Official
Advanced
DynokostyaDynokostya
12

ddd-architecture-python

Apply Domain-Driven Design tactical patterns to Python codebases.

Community
Advanced
manorfmmanorfm

unit-testing-testify

Create and maintain Go unit tests with testify table-driven tests and mocks.

Community
Intermediate
silvioubaldinosilvioubaldino
2

go-unit-tests

Writes and fixes Go unit tests using table-driven tests with testify and testify/mock.

Community
Intermediate