redbox-test-verification

Stars12

Forks16

UpdatedMarch 3, 2026 at 04:50

Ensure every new service or controller gets Mocha or Bruno coverage by analyzing the implemented code and writing integration tests.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

redbox-mint

redbox-mint/redbox-portal

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	Redbox Test Verification
description	Ensure every new service or controller gets Mocha or Bruno coverage by analyzing the implemented code and writing integration tests.

Skill: Redbox Test Verification

Purpose

Use this skill whenever new business logic or routes are merged so the functionality can be verified by automated tests before release.

Analyze first

Inspect the new/updated code in packages/redbox-core/src/services (for services) or packages/redbox-core/src/controllers plus config/routes (for routes) to understand the happy path, dependencies, and any edge cases the feature must cover.
Take notes on expected inputs, persisted entities, authorization requirements, and downstream effects; those points become the assertions in the new test.

Mocha service integration coverage

For every new/modified service in packages/redbox-core/src/services, add an integration test under typescript/test/integration/services. Prefer naming the file after the service (e.g., MyService.test.ts).
These are integration tests (no mocking, full-stack). The test should orchestrate creating real data (often via helper seed utilities), let the service execute against the database, and assert on the persisted state or returned payloads.
Import shared fixtures or helpers from typescript/test/integration/services/helpers as needed, but focus on exercising the whole service flow (setup data, call the method or endpoint, then read back the data it should have created/updated).
Keep the tests in TypeScript, run via Mocha inside the Docker test harness, and update any shared fixtures or typescript/test/unit/services/index.ts helpers if required.

Bruno route coverage

When a new controller or route is introduced (or an existing route grows new behavior), add a Bruno scenario under test/bruno that hits the HTTP endpoint through the normal request pipeline.
Reuse existing Bruno test patterns for authentication, parameter passing, and response validation; the new suite should cover the new route name/path plus potential role restrictions.
Keep suites grouped under the relevant Bruno folder (e.g., test/bruno/general) and ensure the new file is wired into the test/bruno/run scripts if needed.
Do not toggle CSRF headers/flags in route configs; the Bruno environments already disable CSRF globally in Sails config, so follow the default route definitions.

Verify by running the suites

After adding the tests, run the Mocha suite with npm run test:mocha:mount (local iteration) or npm run test:mocha (CI) to build confidence that the service behaves as expected.
For the Bruno scenarios, run npm run test:bruno:general:mount (or the appropriate profile) and ensure the new route passes before finishing.

Documentation

If the new tests uncover side effects or contract changes, document them in the wiki page that best fits (see support/wiki/redbox-core.md or support/wiki/Redbox-Loader.md).

More from this repository

same repository

redbox-angular-apps

redbox-mint/redbox-portal

ReDBox uses embedded Angular applications within EJS views instead of a single SPA. Each feature is often its own Angular project.

2026-03-0312

redbox-angular-services

redbox-mint/redbox-portal

Angular services in ReDBox typically extend `HttpClientService` to handle base URLs, configuration, and CSRF protection.

2026-03-0312

redbox-controllers

redbox-mint/redbox-portal

ReDBox controllers live in `@researchdatabox/redbox-core` and are surfaced to Sails.js through generated shims.

2026-03-0312

redbox-feature-design-planner

redbox-mint/redbox-portal

Create detailed feature designs, implementation plans, and task lists for ReDBox/Redbox features that use Waterline models, services, webservice (REST) controllers, ajax controllers, embedded Angular apps, views, and navigation config. Use when asked to design/plan a feature or produce a task list for this stack, especially when explicit sections, non-SPA Angular patterns, and interleaved tests are required.

2026-03-0312

redbox-feature-implementation-review

redbox-mint/redbox-portal

Review completed ReDBox feature implementations against a growing ruleset and emit structured issues for agent remediation.

2026-03-0312

redbox-form-components

redbox-mint/redbox-portal

Build or update ReDBox form field components end-to-end across Angular form rendering and sails-ng-common config typing/visitor infrastructure. Use when creating a new form component class/model, adding component config properties, wiring component dictionaries, handling config migration/template extraction, or adding form-component tests.

2026-03-0312

Skill: Redbox Test Verification

Purpose

Use this skill whenever new business logic or routes are merged so the functionality can be verified by automated tests before release.

Analyze first

Inspect the new/updated code in packages/redbox-core/src/services (for services) or packages/redbox-core/src/controllers plus config/routes (for routes) to understand the happy path, dependencies, and any edge cases the feature must cover.

Take notes on expected inputs, persisted entities, authorization requirements, and downstream effects; those points become the assertions in the new test.

Mocha service integration coverage

For every new/modified service in packages/redbox-core/src/services, add an integration test under typescript/test/integration/services. Prefer naming the file after the service (e.g., MyService.test.ts).

These are integration tests (no mocking, full-stack). The test should orchestrate creating real data (often via helper seed utilities), let the service execute against the database, and assert on the persisted state or returned payloads.

Import shared fixtures or helpers from typescript/test/integration/services/helpers as needed, but focus on exercising the whole service flow (setup data, call the method or endpoint, then read back the data it should have created/updated).

Keep the tests in TypeScript, run via Mocha inside the Docker test harness, and update any shared fixtures or typescript/test/unit/services/index.ts helpers if required.

Bruno route coverage

When a new controller or route is introduced (or an existing route grows new behavior), add a Bruno scenario under test/bruno that hits the HTTP endpoint through the normal request pipeline.

Reuse existing Bruno test patterns for authentication, parameter passing, and response validation; the new suite should cover the new route name/path plus potential role restrictions.

Keep suites grouped under the relevant Bruno folder (e.g., test/bruno/general) and ensure the new file is wired into the test/bruno/run scripts if needed.

Do not toggle CSRF headers/flags in route configs; the Bruno environments already disable CSRF globally in Sails config, so follow the default route definitions.

Verify by running the suites

After adding the tests, run the Mocha suite with npm run test:mocha:mount (local iteration) or npm run test:mocha (CI) to build confidence that the service behaves as expected.

For the Bruno scenarios, run npm run test:bruno:general:mount (or the appropriate profile) and ensure the new route passes before finishing.

Documentation

If the new tests uncover side effects or contract changes, document them in the wiki page that best fits (see support/wiki/redbox-core.md or support/wiki/Redbox-Loader.md).