testing

Validate backend logic with unit and integration tests for HTTP routes and Postgres.

Updated Apr 14, 2026
One-click install
npx skills add https://github.com/weiloon1234/Forge-Starter --skill testing-weiloon1234
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: testing
Source: https://github.com/weiloon1234/Forge-Starter/tree/main/.claude/skills/testing
Command: npx skills add https://github.com/weiloon1234/Forge-Starter --skill testing-weiloon1234

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Use when writing or extending test coverage for backend code — pure-function unit tests inside src/domain/services/<name>_service.rs, or end-to-end integration tests under tests/<scenario>.rs that boot the real HTTP kernel + real Postgres and hit endpoints with authentic auth tokens. Covers the decision between unit vs integration tests, the shared boilerplate (reset_database / run_cli / boot_api / send_json), authenticated-request patterns, fixture construction, and test-database safety. Does NOT cover frontend component or E2E tests (no vitest / playwright set up yet), benchmarks, property-based tests, or Forge framework tests.

Core Features & Use Cases

  • Unit tests live alongside the tested module, using a #[cfg(test)] mod tests to exercise pure functions in the domain service.
  • Integration tests live under tests/ and exercise HTTP endpoints with a real database, including authentication.
  • Shared boilerplate and patterns: reset_database, run_cli, boot_api, send_json, fixture builders, and test helpers to ensure safe, repeatable tests.

Quick Start

Begin by adding a unit test for a function in the target service, then create an integration test scenario under tests/ that boots the real kernel and hits an endpoint with a valid auth token.

Frequently Asked Questions about testing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure Rust backend unit and integration tests for domain services and HTTP routes?

Rust backend unit tests belong inside a #[cfg(test)] mod tests block within the domain service module, while integration tests live under the tests/ directory to exercise HTTP endpoints and real database interactions. This separation ensures pure logic and end-to-end flows are validated independently.

What boilerplate utilities are needed for integration tests hitting real Postgres databases?

Integration tests against real Postgres require shared boilerplate utilities including reset_database to clear state, boot_api to start the HTTP kernel, run_cli for commands, and send_json for authenticated request payloads. These helpers ensure repeatable and safe test-database interactions.

When should I write a unit test versus an integration test for backend logic?

Write unit tests for pure functions inside domain services to validate isolated logic quickly, and use integration tests under tests/ when you need to exercise HTTP routes with authentic auth tokens and real database interactions. Choose integration tests for end-to-end flow validation.

Does this cover frontend E2E tests or property-based benchmarks?

No, this does not cover frontend component tests, E2E tests, benchmarks, property-based tests, or Forge framework tests. It applies exclusively to backend unit tests inside domain services and integration tests exercising HTTP routes with real Postgres databases.

How do I construct fixtures and ensure test-database safety for Rust integration tests?

Use fixture builders and shared test helpers to construct deterministic data, and call reset_database before each test run to ensure test-database safety. This prevents state leakage between tests and guarantees repeatable end-to-end integration test execution.