Industry practices ยท Practice 5 of 10

Move confidence down the test pyramid

The usual remedy for an ice-cream cone is to keep a small set of end-to-end journeys that cover critical paths and to push the rest of the checks to cheaper layers. For a frontend, the middle layer is component tests that render a module in isolation with stubbed data (Testing Library, Storybook interaction tests, Playwright component testing). Kent C. Dodds's "testing trophy" is a frontend-specific variant of the pyramid that puts most of the weight on this integration-of-components layer.

Between frontend modules and microservices, consumer-driven contract testing replaces many integrated tests. Ian Robinson described consumer-driven contracts in 2006, and Pact is the most widely used implementation. Each UI module records the requests it makes and the responses it relies on, the contract is published to a broker, and each service's pipeline verifies that it still honours every consumer's contract. Pact's can-i-deploy check can then confirm, before any system test starts, that every version listed in a release manifest (practice 1) is compatible with every other version in it, which moves most cross-service breakage out of the slow UI stage.

In GoCD

Features to use

  • Component tests run as an early stage of each module pipeline, before any UI stage.
  • Provider verification runs as a stage in each service pipeline and publishes its result to the Pact Broker with the Pact CLI.
  • A can-i-deploy task in the release-assembly pipeline checks the manifest before system tests start, and its failure stops the release stage.

Gaps

  • GoCD has no Pact integration. A new consumer contract should trigger verification in the provider's pipeline, which means a Pact Broker webhook calling the GoCD scheduling API.
  • Dependencies between the frontend mono repo and the service repositories are not modelled by GoCD materials, so the broker holds the record of which consumer depends on which provider.

Pros and cons for this system

Pros

  • Component and contract tests run in seconds and rarely flake, which shrinks both the duration and the flake rate of the gate.
  • Contract checks find cross-service breakage before any system test starts, and can-i-deploy answers the compatibility question for a whole manifest.
  • The surviving end-to-end journeys are few enough to keep reliable.

Cons

  • Moving checks out of the UI suites means rewriting a large number of existing tests.
  • Contract testing only covers the interactions that consumers record, and it needs every service team to publish and verify contracts through a shared broker.
  • Cutting end-to-end coverage too far loses checks on behaviour that only appears when the whole system runs together.

Sources

Addresses ice-cream cone, integrated tests used as the gate, distributed monolith.

Sources Mike Cohn, Succeeding with Agile (2009), summarised in Martin Fowler's "TestPyramid"; Kent C. Dodds, "The Testing Trophy and Testing Classifications"; Ian Robinson on martinfowler.com, "Consumer-Driven Contracts: A Service Evolution Pattern" (2006); Pact Foundation, "Can I Deploy"; Testing Library; Playwright component testing.