Testing
Your SLI implementation is code. Your alerting rules are code. Your Prometheus recording rules are code. All of it can and should be tested — before it goes into production, before an incident shows you that your alert fires three hours too late or routes to the wrong Slack channel. This
Testing
Event-driven systems fail in slow, invisible ways. A service publishes an event with a renamed field. The consumers don't know yet. Production breaks hours later when the queue drains. Your unit tests all pass because each service tests in isolation. This is the core challenge of EDA
Testing
Event-driven architecture is powerful and notoriously hard to test. Events flow asynchronously between services, state changes propagate eventually, and a bug might not surface until several events down a chain. Standard request/response testing patterns don't apply. You need a different mental model. The Core Testing Challenge
Testing
Error guessing is the test design technique that most testers use without realizing it's a technique. You look at a form and immediately think: "What happens if I put a script tag in this field?" You see a pagination component and wonder: "What happens on
Testing
Testing in production is expensive. Testing against reality is sometimes impossible. A self-driving car cannot accumulate millions of edge-case miles before launch. A satellite cannot be rebooted mid-orbit. A financial exchange cannot be stress-tested with real market crashes on demand. Simulation fills the gap — and doing
Ruby
SimpleCov is the standard code coverage library for Ruby. It hooks into Ruby's Coverage module, tracks which lines and branches your tests exercise, and generates HTML reports so you can see exactly what's untested. Installation # Gemfile group :test do gem 'simplecov', require: false end
Testing
Multi-window burn rate alerting is the approach Google recommends in the SRE Workbook for SLO-based alerting. It avoids the problems with simple threshold alerting (too many false positives, or alerts that only fire hours into an incident). But it's also complex enough that bugs in the
Web3
The ERC-20 standard is deceptively simple. Nine functions, two events, a few rules about return values — it reads like a two-hour implementation job. But a production ERC-20 token with extensions (burnable, mintable, permit, votes, pausable) touches enough edge cases that incomplete test suites routinely ship tokens with
Testing
A cryptographic implementation that is mathematically correct can still be completely broken. If AES-256 takes 1μs longer when the key byte is 0xFF, an attacker who can make 10 million requests can recover that byte. This is a timing side-channel. If your RSA implementation accesses different cache lines
Testing
"Shift left" has been the dominant testing philosophy for the past decade. Move testing earlier in the development cycle. Catch bugs before they reach staging. Catch them before they reach code review. Catch them before they even exist, with type systems and linters. The underlying idea is sound:
Testing
Equivalence partitioning and boundary value analysis are two of the oldest and most effective black-box test design techniques. They are taught in every software testing curriculum, appear on every certification exam, and yet are frequently applied mechanically without real understanding — resulting in test suites that look thorough but miss
Test Strategy
Shift-left testing means moving testing earlier in the development lifecycle — from post-development to during and before development. The premise is simple: bugs caught at the requirements stage cost a fraction of what they cost in production. The practices vary (TDD, static analysis, contract testing, developer-run tests) but