Skip to content
SDLC Studio

Test specs, test code and test environments

The acceptance criteria decide whether a story is done. This section is about the layer that makes them real tests rather than good intentions.

Test specifications

Section titled “Test specifications”

A test spec consolidates the plan, the suites, the cases and the fixtures into one document per epic. Its job is a mapping: every acceptance criterion to a named test case.

/sdlc-studio test-spec                  # from epics and stories - greenfield
/sdlc-studio test-spec --epic EP0001    # one epic
/sdlc-studio test-spec generate         # reverse-engineer specs from tests you already have
/sdlc-studio test-spec review           # are the criteria still covered?

test-spec review is the one to run after a spec changes. Criteria drift; a spec that mapped cleanly three sprints ago may now be pointing at cases that no longer exist.

Test code

Section titled “Test code”
/sdlc-studio test-automation                       # everything pending
/sdlc-studio test-automation --spec TS0001         # one spec
/sdlc-studio test-automation --type unit           # or integration, or e2e
/sdlc-studio test-automation --framework pytest    # override the detected framework

It detects your language and framework and generates executable code from the specs. The generated tests are ordinary files in your repository under your test runner - not a proprietary format and not something only the tool can run.

Name the mutant first

Section titled “Name the mutant first”

The single most useful habit in this section, and it applies whether the test is generated or hand-written:

Before writing a test, state the production change it must fail on. Then break the code on purpose and check the test dies.

A test that passes whatever you do to the code is a test of nothing. This project has found its own. Mutation testing is the mechanical form of the same check.

Test environments

Section titled “Test environments”

Integration and end-to-end tests usually need something running - a database, a queue, a fake payment endpoint.

/sdlc-studio test-env setup    # generate docker-compose.test.yml, from the TRD
/sdlc-studio test-env up       # start it
/sdlc-studio test-env status   # are the services healthy?
/sdlc-studio test-env down     # stop and clean up

The environment is generated from the TRD, so the services the tests run against are the ones the architecture says exist. When the TRD changes, regenerate rather than patching a compose file by hand until it diverges from the design.

Verification depth

Section titled “Verification depth”

A fix records how it was verified, not merely that it was. The tiers are enforced at the status gate: a bug cannot reach Fixed below functional depth, and a production-affecting one cannot reach Closed below soak.

That distinction translates directly: “we fixed it” and “we fixed it and it survived a weekend in production” are different claims, and the tooling makes you say which one you are making.

Where to next

Section titled “Where to next”