| name | testing |
| description | Sounding-first testing patterns for The Boring JavaScript Stack — one test() API, a Sails-centered trial context, worlds under tests/, JSON and Inertia request testing, mail capture, and browser-capable trials only when the browser truly matters. Use this skill when writing, configuring, or debugging tests in a Sails.js + Inertia.js application.
|
| metadata | {"author":"sailscastshq","version":"2.0.0","tags":"testing, sounding, sails, node-test, playwright, inertia, e2e, unit-tests, boring-stack"} |
Testing
The Boring JavaScript Stack now has one primary testing story: Sounding.
Sounding keeps the familiar test() API, but gives Sails apps one coherent runtime for:
- helper and business-logic trials
- JSON endpoint and policy behavior
- Inertia page contracts
- mail assertions
- browser-capable flows when the browser truly matters
When to Use
Use this skill when:
- Writing or restructuring tests in a Sails.js + Inertia.js application
- Migrating older
node:test, Playwright, or inertia-sails/test suites to Sounding
- Designing
tests/unit, tests/e2e/pages, tests/factories, and tests/scenarios
- Configuring
config/sounding.js and config/env/test.js
- Writing trials around
sails.helpers, get() / post(), visit(), auth, login, mailbox, or page
- Choosing between virtual transport and real HTTP transport
- Keeping mail capture, datastore isolation, and browser setup calm and predictable
- Selecting named browser projects such as
desktop, mobile, or safari
- Debugging failed browser trials with Sounding's default URL/screenshot artifacts and opt-in traces/videos
- Setting up CI around a Sounding-powered suite
Sounding Mental Model
Keep these terms straight and use them consistently:
- a trial is one named behavior the app must prove
- the trial context is the object Sounding passes into
test()
sails is the canonical center of that context- a world is the named business situation the trial lives inside
- an actor is the role operating through that world
- a suite is the whole organized test tree for the app
Prefer Sounding's public shape:
const { test } = require('sounding')test('...', async ({ sails, get, visit, auth, login, page, expect }) => {})sails.helpers.*sails.sounding.*
Do not push people back toward:
- ad hoc
getSails() boot helpers
inertia-sails/test as the main integration story- Playwright for every request-level behavior
tests/sounding/ as a framework-branded island
Rules
Read the rule files that match the work you are doing:
- rules/getting-started.md - Sounding philosophy, suite layout, scripts, and migration mindset
- rules/unit-testing.md - helper trials, pure business logic, worlds, factories, and scenarios
- rules/integration-testing.md - request-level JSON and Inertia trials with
get(), post(), and visit()
- rules/e2e-testing.md - browser-capable trials with
{ browser: true }, page, login, and mobile-aware flows
- rules/test-configuration.md -
config/sounding.js, config/env/test.js, datastores, mail capture, cleanup, and CI
