Skill library

Skill library
Developerskills/developer/test-cases-technical/SKILL.md

Technical Test Cases

Load, performance, and security testing owned by developers. The complement to functional tests.

Technical Test Cases

Technical test cases verify that the system holds up under load, meets performance targets, and resists predictable attack patterns. Where functional tests (developer/test-cases-functional) ask "does it work when used as intended?", technical tests ask "does it work when used badly, used a lot, or used adversarially?"

Technical tests are owned by the developer who built the feature. They live in the same repository as the feature, run in CI, and gate the same release as the functional tests do.

Load testing

Load tests verify the system performs to spec under realistic concurrent usage. The targets come from the spec's Performance section (developer/requirements-specification); the tests come from us.

Tooling. k6 for HTTP-level tests, Pusher's load testing helpers for WebSocket flows, custom harnesses for AI Diary generation (which has cost as well as latency dimensions).

Standard SPYN scenarios.

  • Diary feed scroll: 200 concurrent users, 50 RPS each, mixed cache hits and cache misses.
  • AI Diary generation kickoff: 100 concurrent generations, measuring queue depth, OpenAI Assistant API latency, completion time p50/p95/p99.
  • WebSocket fan-out: 1,000 connected clients on a single channel, latency from publish to last-received.
  • Image upload + Google Vision moderation: 50 concurrent uploads of 4MB images.

Pass criteria. p95 latency ≤ spec target, error rate ≤ 0.5%, no unbounded queue growth, no memory leak across a one-hour soak.

Performance testing

Performance tests are the smaller cousins of load tests: single-request, focused on the cost of a specific operation. They catch regressions early — a query that goes from 5ms to 50ms is a 10x regression even if no load test would have flagged it.

Performance tests run on every PR; the test record includes the p95 over the last 50 runs so reviewers see drift, not just absolute numbers.

Security testing

Owned by the developer; reviewed by the Security Lead at code review time.

Automated.

  • Dependency scanning on every PR (GitHub Advisory Database, Snyk equivalent for npm and Composer).
  • Static analysis: TypeScript strict mode, PHPStan level 8 on the Laravel backend.
  • Secret scanning enforced server-side; commits with detected secrets are rejected before merge.

Manual per feature.

  • Auth checks: can a user access another user's resource? Test with at least one row of contrast data.
  • Injection: SQL injection on every parameterised query, command injection on every shell-out, prompt injection on every LLM call.
  • Authorization across roles: SuperAdmin / Admin / User boundaries enforced server-side, not just hidden in UI.
  • Rate limiting: brute force resistant on auth endpoints, AI generation resistant to abuse.

Quarterly. External penetration test against the staging environment with full source-code access for the testers.

Accessibility testing (technical layer)

Functional tests check WCAG observable outcomes; technical tests verify the underlying contract. ARIA attributes present where required, keyboard navigation order correct, focus management on modals and overlays, motion-sensitive content respecting prefers-reduced-motion. axe-core runs in CI.

Failure handling

A failing technical test is a build failure. The developer fixes it before re-requesting review. Persistent flakes are tracked in a flake budget; tests that exceed the budget get quarantined and assigned an owner to either fix or retire.

Owned by

Engineering Leadership, with the Security Lead as co-owner for the security section. Audited by the Master skill on a 90-day cadence.