← Graph

Rails Testing Pyramid (Ivan's version)

concept 2 connections

Heuristic Ivan Nemytchenko credits to a conversation with Nathan Ladd. Tests can go 'deep' (unit tests covering core logic — services, mutators) or 'wide' (controller/functional/acceptance tests touching many endpoints). Over-unit-testing models yields fragile tests that are expensive to maintain, pushing developers toward acceptance tests that rely on flaky DOM ids driven by Ajax. The right questions when writing a test: is it useful, easy to write, easy to support, how fragile is it, how often will it need rewriting. Highest-ROI starting point: controller tests hitting every endpoint (success responses on reads; correct effects on create/update/delete). Then unit-test services and mutators for core logic. Combined with named routes and i18n everywhere, controller tests indirectly exercise routing, services, models, and strings.

category
methodology
about
Rails Testing Pyramid (Ivan's version) concept
Presents a depth-vs-width test strategy credited to a conversation with Nathan Ladd.
concept Rails Testing Pyramid (Ivan's version)
related_to
Nathan Ladd person
Ivan credits Nathan Ladd with the 'deep vs wide' testing model shared in conversation at the conference.

Provenance

Read by
16 extractions