home / skills / falkicon / mechanic / s-test

s-test skill

needs review

This skill helps you write and run unit tests for World of Warcraft addons using Busted and Mechanic, improving coverage and reliability.

npx playbooks add skill falkicon/mechanic --skill s-test

Review the files below or copy the command above to add this skill to your agents.

Files (3)

SKILL.md

2.4 KB

---
name: s-test
description: >
  Write and run unit tests for WoW addons using Busted and the Mechanic test
  framework. Covers test structure, mocking WoW APIs, and coverage analysis.
  Use when adding tests, fixing bugs with regression tests, or improving coverage.
  Triggers: test, unit test, coverage, Busted, mock, TDD, sandbox.
---

# Testing WoW Addons

Expert guidance for testing WoW addons using Sandbox, Desktop, and In-Game methods.

## Related Commands

- [c-test](../../commands/c-test.md) - Run unit tests workflow
- [c-review](../../commands/c-review.md) - Full code review (includes test step)

## CLI Commands (Use These First)

> **MANDATORY**: Always use CLI commands before manual exploration.

| Task | Command |
|------|---------|
| Generate Stubs | `mech call sandbox.generate` |
| Run Sandbox Tests | `mech call sandbox.test -i '{"addon": "MyAddon"}'` |
| Run Busted Tests | `mech call addon.test -i '{"addon": "MyAddon"}'` |
| Test Coverage | `mech call addon.test -i '{"addon": "MyAddon", "coverage": true}'` |
| Sandbox Status | `mech call sandbox.status` |

## Capabilities

1. **Sandbox Testing** — Fast, offline tests using generated WoW API stubs
2. **Desktop Testing (Busted)** — Integration tests with custom mocks
3. **In-Game Testing** — Runtime verification via MechanicLib registration
4. **Coverage Analysis** — Identify untested code paths

## Routing Logic

| Request type | Load reference |
|--------------|----------------|
| Sandbox, Busted, In-Game guides | [../../docs/integration/testing.md](../../docs/integration/testing.md) |
| Busted spec patterns | [references/busted-patterns.md](references/busted-patterns.md) |
| Mocking WoW APIs | [references/wow-mocking.md](references/wow-mocking.md) |
| MechanicLib test registration | [../../docs/integration/mechaniclib.md](../../docs/integration/mechaniclib.md) |

## Quick Reference

### Recommended Workflow
1. **Sandbox (Core)**: Fast feedback for business logic.
2. **Desktop (Integration)**: Test interactions between modules.
3. **In-Game (Verification)**: Final check against live APIs.

### Example Sandbox Test
```lua
describe("MyAddon Core", function()
    it("calculates values correctly", function()
        local result = Core.Calculate(10, 20)
        assert.equals(30, result)
    end)
end)
```

### Running Tests
```bash
# Generate stubs once
mech call sandbox.generate

# Run tests frequently
mech call sandbox.test -i '{"addon": "MyAddon"}'
```

Overview

This skill helps you write and run unit tests for World of Warcraft addons using Busted and the Mechanic test framework. It covers test structure, mocking WoW APIs, running sandbox and in-game tests, and performing coverage analysis. Use it to add tests, prevent regressions, and improve code quality and coverage.

How this skill works

The skill guides you through a recommended workflow: generate API stubs, run fast sandbox tests, run desktop Busted integration tests with mocks, then verify in-game via MechanicLib registration. It explains how to mock WoW globals and APIs, structure Busted specs, and gather coverage reports. CLI commands are emphasized for reproducible automation and repeatable results.

When to use it

When adding unit or integration tests for a new feature
When fixing bugs and writing regression tests
When you need to mock WoW APIs for offline testing
When increasing test coverage and identifying untested code paths
Before releasing changes that touch core logic or addon APIs

Best practices

Generate WoW API stubs once and keep them updated to avoid false negatives
Start with sandbox tests for fast feedback, then add desktop and in-game tests for integration and runtime checks
Mock only external WoW or addon boundaries; keep business logic pure and easy to test
Use clear Busted describe/it structure and name tests for behavior, not implementation
Run coverage analysis regularly and add tests for critical untested paths

Example use cases

Write a sandbox test to validate core calculation functions without WoW dependencies
Use Busted with custom mocks to test module interactions and event handling
Register MechanicLib tests to run quick in-game verification for API-dependent behavior
Add a regression test when fixing a bug to prevent reintroduction
Run coverage reports to prioritize tests for high-risk code paths

FAQ

Do I need the CLI to run tests?

Yes. The CLI commands are mandatory for generating stubs and running sandbox and Busted workflows; they ensure consistent, reproducible test runs.

How do I handle global WoW APIs in tests?

Generate WoW API stubs for sandbox testing and use focused mocks in Busted for desktop integration. Reserve in-game tests for verifying runtime interactions.