traxxall-dev-tests

When to invoke

Invoke when the user asks to:

• "Write tests for" a WI or implementation change.
• "Scaffold unit tests" or "outline regression tests".
• "Author dev tests" for a specific component change.

This skill produces author-side test stubs. It does NOT produce:

• QA Playwright tests.
• Blind-adversarial acceptance tests.
• Integration tests that run against live infrastructure.
• Any test that involves the destructive utility projects.

---

Step 1: Load standards

Read skills/traxxall-standards/SKILL.md for the dev test boundary rules:

• Author-side tests use UnitTests.Core with TransactionScope rollback.
• Destructive utility projects (cache manipulation, mock data population) must never be run automatically.
• The skill writes tests; it does not run them.

---

Step 2: Identify the test subject

From the intake brief or user input:

• Which project is being changed (legacy vs modern vs shared)?
• Which component or operation is being tested?
• What are the observable outcomes to verify (from the acceptance criteria or WI description)?

Do not derive test subjects from class names or method signatures the user provides as requirements. Derive them from observable behaviour: what the system does differently after the change.

---

Step 3: Determine the test project

Changed code area	Test project
Traxxall.Web, Traxxall.Admin, Traxxall.WebApp, Traxxall.WebApi	UnitTests.Core (or the legacy-adjacent test project for the module)
Traxxall.NETCore.WebApi, Traxxall.v2.UniversalAPI	UnitTests.Core or the modern module's own test project
Traxxall.Core, Traxxall.Models	UnitTests.Core
Traxxall.v2.Infrastructure*	UnitTests.Core

When in doubt, use UnitTests.Core. Do not create a new test project; fit within the existing structure.

---

Step 4: Write test stubs

For each observable outcome to verify, write one test stub.

TransactionScope rollback pattern

Every test that touches the database must follow this pattern exactly:

// STUB — author-side dev test. Review before running.
// Project: UnitTests.Core
// DO NOT run in CI without manual review.
// DO NOT run the destructive utility projects.

[TestMethod]
public void {TestName}_WhenCondition_ReturnsExpectedOutcome()
{
    // ARRANGE
    using var scope = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled);
    // Set up test data — insert or configure only what this test requires.
    // {describe what test data to set up in plain language — not code}

    // ACT
    // {describe the operation to invoke in plain language — not code}
    // Example: invoke the query/command that implements the behaviour under test.

    // ASSERT
    // {describe the observable result to verify — not internal state}
    // Example: Assert.AreEqual(expectedCount, actualCount) or check the returned value.

    // ROLLBACK — never call scope.Complete()
    // Scope disposes without committing — no persistent state.
}

Test naming convention

{MethodOrBehaviour}_{Condition}_{ExpectedOutcome}

Examples:

• AdminGrid_WhenQueryRunsForTenant_ReturnsOnlyTenantRows
• ComplianceReport_WhenRecordMissingAD_ReturnsMissingStatus
• UniversalApiEndpoint_WhenPayloadEmpty_Returns400

Test categories

Author at minimum two stubs per WI or component change:

1. Happy-path test: the system behaves correctly under normal input and state.
2. Edge / error test: the system behaves correctly when input is missing, invalid, or at a boundary.

Add additional stubs for:

• Tenant isolation (when the change touches multi-tenant queries: verify one tenant cannot see another's data).
• Roll-forward / idempotency (when the change involves a schema migration or data population).

---

Step 5: Produce the test outline

## Dev-Test Outline — WI #{WI#}: {Title}

### Test project
UnitTests.Core

### Pattern
TransactionScope rollback (non-destructive). Every database operation is wrapped in a
TransactionScope that is never committed. No persistent state is left after any test run.

### IMPORTANT
- These stubs must be reviewed by the developer before running.
- Do NOT run in CI without explicit manual review of each stub.
- Do NOT invoke the destructive utility projects (cache manipulation, mock data population).
- These stubs are author-side tests only. QA Playwright tests are authored separately.

---

### Stub 1: {TestName}
**Scenario**: {one sentence — what observable behaviour this test verifies}
**Category**: Happy-path | Edge case | Error case | Tenant isolation

```csharp
[TestMethod]
public void {TestName}_{Condition}_{ExpectedOutcome}()
{
    // ARRANGE
    using var scope = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled);
    // {describe test data setup}

    // ACT
    // {describe the operation}

    // ASSERT
    // {describe what to verify}

    // ROLLBACK — do not call scope.Complete()
}

Notes: {any specific concern — e.g., "verify the query does not cross tenant boundaries", "confirm no row is written after scope disposes"}

---

Stub 2: {TestName}

...

---

## Step 6: Shared-core test considerations

When the changed component is in `Traxxall.Core`, `Traxxall.Models`, or `Traxxall.v2.Infrastructure*`:

1. Author tests that verify the shared component's behaviour in isolation.
2. Note which consuming projects' behaviour may be affected (from the blast-radius summary).
3. Add a comment in each stub: `// Shared core change — run this test after each consuming project's integration passes.`
4. Do not attempt to write end-to-end tests spanning both legacy and modern API surfaces in a single stub. Each surface gets its own stub.

---

## Guardrails

- Never produce QA Playwright tests, acceptance test automation, or blind-adversarial test content.
- Never call `scope.Complete()` in any test stub. Every scope must roll back.
- Never reference the destructive utility projects as a test dependency.
- Never suggest running tests automatically in CI without explicit human review.
- Never derive test scenarios from implementation details (class names, method signatures). Derive them from observable behaviour described in the intake brief or AC.
- The developer runs the tests; this skill only writes the stubs.

---

## Output envelope (result shape)

```json
{
  "wi_number": 16472,
  "test_project": "UnitTests.Core",
  "pattern": "TransactionScope rollback",
  "stub_count": 3,
  "stubs": [
    {
      "name": "AdminGrid_WhenQueryRunsForTenant_ReturnsOnlyTenantRows",
      "category": "happy-path",
      "shared_core": false
    },
    {
      "name": "AdminGrid_WhenOtherTenantId_ReturnsEmpty",
      "category": "tenant isolation",
      "shared_core": false
    },
    {
      "name": "AdminGrid_WhenNullInput_DoesNotThrow",
      "category": "edge case",
      "shared_core": false
    }
  ],
  "ci_safe": false,
  "destructive_projects_referenced": false
}

ci_safe is always false — stubs require manual review before CI inclusion. destructive_projects_referenced must always be false.