mcpField
S
stress-testing

stress-testing

github.com/aj-geddesTesting & quality373499 installsUpdated 34w ago
Repository

About stress-testing

A skill for planning stress tests that probe system capacity, failure behavior, and recovery. It is intended for teams validating systems under heavy or unusual load, with reference guides covering several test approaches.

Key features

  1. 01Capacity and breaking-point analysis
  2. 02Spike and soak testing guidance
  3. 03Auto-scaling validation
  4. 04Failure recovery checks
  5. 05Load monitoring and cleanup practices

Use cases

  1. 01Finding capacity limits before deployment
  2. 02Checking behavior during traffic spikes
  3. 03Validating recovery after failures
  4. 04Planning capacity and graceful degradation

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/aj-geddes/useful-ai-prompts --skill stress-testing

After installing, type/stress-testingin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
auto-scaling-validation.md
breaking-point-analysis.md
jmeter-stress-test.md
k6-stress-testing.md
soakendurance-testing.md
spike-testing.md
scripts/
scaffold-tests.sh
templates/
test-template.js

Details

From the project README

Stress Testing

Table of Contents

Overview

Stress testing pushes systems beyond normal operating capacity to identify breaking points, failure modes, and recovery behavior. It validates system stability under extreme conditions and helps determine maximum capacity before degradation or failure.

When to Use

  • Finding system capacity limits
  • Identifying breaking points
  • Testing auto-scaling behavior
  • Validating error handling under load
  • Testing recovery after failures
  • Planning capacity requirements
  • Verifying graceful degradation
  • Testing spike traffic handling

Quick Start

Minimal working example:

// stress-test.js
import http from "k6/http";
import { check, sleep } from "k6";
import { Rate } from "k6/metrics";

const errorRate = new Rate("errors");

export const options = {
  stages: [
    // Stress testing: Progressive load increase
    { duration: "2m", target: 100 }, // Normal load
    { duration: "5m", target: 100 }, // Sustain normal
    { duration: "2m", target: 200 }, // Above normal
    { duration: "5m", target: 200 }, // Sustain above normal
    { duration: "2m", target: 300 }, // Breaking point approaching
    { duration: "5m", target: 300 }, // Sustain high load
    { duration: "2m", target: 400 }, // Beyond capacity
    { duration: "5m", target: 400 }, // System under stress
    { duration: "5m", target: 0 }, // Gradual recovery
  ],
  thresholds: {
    http_req_duration: ["p(99)<1000"], // 99% under 1s during stress
    http_req_failed: ["rate<0.05"], // Allow 5% error rate under stress
    errors: ["rate<0.1"],
  },
// ... (see reference guides for full implementation)

Reference Guides

Detailed implementations in the references/ directory:

GuideContents
k6 Stress Testingk6 Stress Testing
Spike TestingSpike Testing
Soak/Endurance TestingSoak/Endurance Testing
JMeter Stress TestJMeter Stress Test
Auto-Scaling ValidationAuto-Scaling Validation
Breaking Point AnalysisBreaking Point Analysis

Best Practices

✅ DO
  • Test in production-like environment
  • Monitor all system resources
  • Gradually increase load to find limits
  • Test recovery after stress
  • Document breaking points
  • Test auto-scaling behavior
  • Plan for graceful degradation
  • Monitor for memory leaks
❌ DON'T
  • Test in production without safeguards
  • Skip recovery testing
  • Ignore warning signs (CPU, memory)
  • Test only success scenarios
  • Assume linear scalability
  • Forget database capacity
  • Skip monitoring third-party dependencies
  • Test without proper cleanup

Comments

Markdown supported