Testing
Storybook stories document your components. Play functions make them executable tests. With @storybook/test and play functions, you can write interactions directly in your stories, run them in the Storybook UI with a visual step-by-step debugger, and execute them headlessly in CI. The result is documentation that is
Testing
Component libraries are the infrastructure of modern frontend development. When a Button component's padding changes, every screen that uses Button changes. When a form field's focus style regresses, every form in your app is affected. Testing at the component level is the highest-leverage place to
Gauge
Gauge plugins communicate with the Gauge runner over a socket using Protocol Buffers. There are three plugin types: language runners (execute step implementations), reporting plugins (generate reports), and general plugins (extend functionality). Building a custom plugin means implementing a small socket server that speaks the Gauge protobuf message format. The
Gauge
Gauge integrates naturally with any CI system: it exits with a non-zero code on failure, writes HTML reports to a configurable directory, and supports environment-specific configuration via the --env flag. GitHub Actions, Jenkins, and Docker each need a slightly different setup — mainly around browser dependencies for UI tests
Storybook
Accessibility bugs are expensive to fix late. A missing ARIA label, a button that cannot receive keyboard focus, or insufficient color contrast ratio — these are straightforward to catch during component development but painful to remediate after a product has shipped. Storybook's @storybook/addon-a11y brings axe-core accessibility
STM32
```tldr STM32 HAL firmware can be unit tested on the host by mocking the STM32CubeHAL functions with CMock. Your application code links against mock HAL functions instead of real hardware peripherals — tests run fast, without an STM32 board, and integrate into CI/CD. ``` ```takeaways Mock HAL functions, not registers. STM32CubeHAL
Serverless
AWS Step Functions lets you orchestrate Lambda functions, ECS tasks, and other AWS services into complex workflows. State machines are powerful, but they're also notoriously difficult to test — executions run asynchronously, state transitions depend on the output of one step feeding into the next, and error handling flows
Testing
Static analysis tools examine code without executing it — catching bugs, security vulnerabilities, and style violations at the moment of writing, before tests run. They're the cheapest form of shift-left testing: zero test infrastructure required, sub-second feedback, and they catch entire categories of bugs that unit tests
Testing
Every non-trivial software system has state. A shopping cart is empty, then has items, then is checked out. A door is locked, unlocked, or open. A connection is connecting, connected, or disconnected. Finite state machines (FSMs) are a precise way to model that state — and state machine testing is
Testing
Manual playtesting can't find every bug before ship. A QA team playing 8 hours a day across 100 levels will miss edge cases that only appear after 40 hours of playtime, or that require a specific sequence of actions in a specific order. Simulation testing addresses this by
Testing
Site Reliability Engineering (SRE) reframes reliability as a software problem. Instead of treating testing and monitoring as separate concerns, SRE treats them as integrated practices built around measurable objectives. This guide covers the core SRE testing practices: SLOs, error budgets, reliability testing, and how they work together. The SRE Testing
Testing
The worst time to learn your incident response process is during an actual incident. Game days, tabletop exercises, and runbook validation are how SRE teams build muscle memory before the real thing happens. This guide covers the full spectrum of incident response testing. Why Incident Response Needs Testing Incident response