test-scenarios

Generates exhaustive ID'd test scenario matrices for Kubernetes operators, CSI drivers, and CRDs.

4|Updated Dec 1, 2025
One-click install
npx skills add https://github.com/simplyblock/simplyblock-operator --skill test-scenarios-simplyblock
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-scenarios
Source: https://github.com/simplyblock/simplyblock-operator/tree/main/.claude/skills/test-scenarios
Command: npx skills add https://github.com/simplyblock/simplyblock-operator --skill test-scenarios-simplyblock

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Writing test plans for Kubernetes controllers often produces shallow happy-path checklists that miss negative cases, boundary conditions, and topology variations where real defects hide. This Skill systematically enumerates a complete, falsifiable test scenario matrix so coverage gaps are declared rather than silently assumed. ## Core Features & Use Cases - Paired positive and negative enumeration: Every positive behavior mechanically derives negatives (absent preconditions, invalid inputs, RBAC denials, control-plane 4xx/5xx/timeout, concurrency conflicts, mid-operation interruption) so no behavior group ships without failure cases. - Coverage axis expansion: Scenarios are expanded across cluster topology (single-node, three-node, 5+), namespace scope, cluster count, failure domains, object scale, lifecycle timing, and version skew, with an auditable axis coverage table. - Honest gap reporting: Untested axis combinations are listed in a gap table with reasons instead of being silently dropped. - Use Case: When designing a new volume migration feature in the simplyblock operator, invoke this Skill to produce the numbered U-/I-/E-/M- scenario rows for the design document's test plan, including single-node no-target cases and operator-restart idempotency checks. ## Quick Start Ask the AI to enumerate the test scenario matrix for a specific feature, CRD, or controller, for example by requesting test scenarios for the storage node drain reconciler.

Frequently Asked Questions about test-scenarios

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

FAQPage Schema
How do I write a test scenario matrix for a Kubernetes operator?

Enumerate one behavior per design decision, derive negatives mechanically from each positive (absent preconditions, invalid inputs, dependency failures, concurrency, interruption), then expand across coverage axes like node count and namespace scope. This Skill automates that workflow and outputs ID'd rows ready for a test plan.

What test cases should a Kubernetes CSI driver or controller cover?

Cover positive outcomes per behavior, negative mutations (4xx/5xx/timeout from the control plane, missing referents, RBAC denials), boundary rows for anything that compares or counts, and topology variations such as single-node, three-node, and multi-namespace clusters.

Does this Skill test the control plane or SPDK backend behavior?

No. Scenarios assert only this repository's responses to its dependencies. The control plane, sbcli, and SPDK are treated as mocked inputs, and backend behaviors become boundary scenarios asserted against a fake control plane.

How are negative test cases derived from positive ones?

Each positive scenario is mutated across preconditions, inputs, referenced objects, dependencies, concurrency, interruption, and resource exhaustion. Every behavior group must end with more negatives than positives, and no-op rows must state how absence is proven, such as a zero mock call count.

When should I not use full cartesian coverage expansion?

Never take the full cartesian product of axes. Cover every axis value at least once, pair axes explicitly only when both feed the same decision function, and declare all remaining untested combinations in a gap table with reasons.