RSpec Testing Pyramid

Build a fast, deterministic Rails test suite. AI agents over-write system specs (slow, flaky), under-write request specs (the sweet spot), and reach for hard-coded id: 1 instead of factories. This skill encodes the layer choices senior Rails devs make.

Why this matters

A bad test suite is worse than no test suite. It slows CI, surfaces false positives, and trains devs to ignore failures. AI agents default to system specs because they read most like the user's intent — but a 200-spec system suite that runs 30 minutes and is 5% flaky is a productivity catastrophe.

The opinion

Pyramid shape: lots of model + request specs (fast, deterministic), few system specs (slow, only critical user flows). Use FactoryBot, not fixtures. RSpec hooks: prefer let over before for setup that's used by some tests; let! only when the side-effect must precede the example. Stub external HTTP — use VCR for cassette-replay, WebMock for hand-rolled stubs. System specs with Cuprite over Selenium (faster, no driver install).

Counter-position: Minitest + Rails fixtures is what DHH and the Rails core team use. It's faster to load and forces simpler tests. For greenfield apps that won't ship to a large dev team, Minitest is fine. We pick RSpec because most ecosystem libraries (FactoryBot, Shoulda Matchers, VCR) target RSpec first and the team-size break-even is around 3+ engineers.

The pyramid (Rails-specific)