running-smoke-tests

name	running-smoke-tests
description	Execute fast smoke tests validating critical functionality after deployment. Use when performing specialized testing. Trigger with phrases like "run smoke tests", "quick validation", or "test critical paths".
allowed-tools	Read, Write, Edit, Grep, Glob, Bash(test:smoke-*)
version	1.20.0
author	Jeremy Longshore <[e-mail]>
license	MIT
tags	["testing","deployment","smoke-tests"]
compatibility	Designed for Claude Code, also compatible with Codex and OpenClaw

Smoke Test Runner

Overview

Execute fast, high-confidence smoke tests that validate critical application functionality after deployment or build. Smoke tests verify that the application starts, core user flows work, and key integrations respond -- without running the full test suite.

Prerequisites

• Application deployed and accessible at a known URL or running locally
• HTTP client available (curl, wget, node-fetch, or Playwright)
• List of critical endpoints and user flows to validate
• Expected response codes and content patterns for each check
• CI/CD pipeline hook for post-deployment validation

Instructions

1. Identify the critical paths that constitute a "working" application:
   • Health check endpoint returns 200 with expected body.
   • Homepage loads and contains key UI elements.
   • Authentication flow succeeds with test credentials.
   • Primary API endpoint returns valid data.
   • Database connection is active and responding.
2. Create a smoke test configuration listing each check:
   • URL or command to execute.
   • Expected HTTP status code (200, 301, etc.).
   • Response body pattern to match (substring or regex).
   • Maximum acceptable response time (e.g., 3 seconds).
3. Write the smoke test suite as a lightweight script or test file:
   • Use curl for HTTP checks or Playwright for browser-based checks.
   • Run checks sequentially for simplicity (parallel for speed if independent).
   • Fail fast on the first critical failure.
   • Log each check result with pass/fail, response time, and status code.
4. Implement timeout guards:
   • Set a global timeout of 60 seconds for the entire smoke suite.
   • Set per-check timeouts of 5-10 seconds.
   • Treat timeouts as failures, not retries.
5. Add deployment-gate integration:
   • On success: proceed with deployment promotion or traffic shifting.
   • On failure: trigger rollback and send alert notification.
   • Report results to CI/CD dashboard and Slack/Teams webhook.
6. Store smoke test results as CI artifacts for audit trail.
7. Schedule periodic smoke runs (every 5 minutes in production) as synthetic monitoring.

Output

• Smoke test script (scripts/smoke-test.sh or tests/smoke.test.ts)