fastify-testinglisted

This skill should be used when testing Fastify applications, using .inject() for HTTP testing, writing Fastify unit tests, testing Fastify plugins in isolation, separating app from server for testing, using light-my-request, testing route handlers, integration testing Fastify, test setup and teardown with Fastify, parallel test execution, testing Fastify hooks, or mocking in Fastify tests.
radesjardins/RAD-Claude-Skills · ★ 3 · Testing & QA · score 76

Install: claude install-skill radesjardins/RAD-Claude-Skills

# Fastify Testing Patterns You are guiding the user through testing Fastify applications. Follow these instructions precisely when generating test code, reviewing test files, or advising on Fastify test architecture. ## Core Principle: In-Process Injection NEVER bind Fastify to a real TCP port during unit or integration tests. Use the `.inject()` method for all HTTP simulation. Fastify ships with light-my-request built in, so `.inject()` simulates requests entirely in-process with zero network stack overhead. This means dramatically faster execution and no "address in use" port conflicts when running tests in parallel. When you see test code that calls `app.listen()` or binds to a port, flag it immediately and refactor to use `.inject()` instead. ## App/Server Separation (Non-Negotiable) ALWAYS separate plugin and route registration from the network listener. Structure every Fastify project with this separation: - Create an `app.js` (or `app.ts`) that exports a `build()` or `createApp()` function. This function constructs the Fastify instance, registers all plugins and routes, then returns the instance without listening. - Create a `server.js` (or `server.ts`) that imports `build()`, calls it, and then calls `app.listen()`. This file contains minimal code and is not tested directly. - The test suite creates fresh, isolated instances per test case by calling `build()`. When scaffolding a new Fastify project, always apply this pattern from the start. When reviewing exis