Skip to content

PATTERN Cited by 1 source

Parallel integration test suite for context switch

Parallel integration test suite for context switch is the discipline of reusing an existing integration-test corpus by running it under a different context — not rewriting the tests, just re-parameterising the context (e.g. org-context instead of workspace-context). The tests that break under the new context are the actionable list of APIs/flows that need to be fixed in the re-architecture. You inherit the coverage rather than forking the corpus.

Canonical wiki instance: Slack's Unified Grid (systems/unified-grid, Source: sources/2024-08-26-slack-unified-grid-how-we-re-architected-slack-for-our-largest-customers).

The verbatim framing

"We created a parallel integration test suite which ran all our existing integration tests using org context instead of workspace context. This let us reuse thousands of tests rather than rewriting them from the ground up. As expected, hundreds of test suites were broken initially, providing us with a concrete list of test suites to fix as part of marking an API compatible with Unified Grid."

Why it works

When a re-architecture changes the context axis the system operates under (workspace-context → org-context), the behaviour of individual APIs is the thing that changed; the shape of valid flows — create a channel, post a message, grant a permission, query unreads — is largely unchanged. An integration test corpus already encodes those flows. Re-running the same flows under the new context:

  • Reveals which APIs broke under the new context — the failed tests.
  • Preserves coverage the team already paid the cost of writing.
  • Makes the re-architecture's correctness measurable — as the list of broken tests shrinks, customer readiness increases.

How it composes with other Slack disciplines

  • patterns/prototype-the-path — the parallel test suite is the objective-quality signal that the dogfood ring's subjective feedback lacks. Dogfood catches UX issues; the parallel test suite catches correctness issues.
  • patterns/two-pass-api-migration — first pass makes the typical-case tests pass; second pass makes the edge-case tests pass. The broken-test list is the second-pass backlog. "Hundreds of test suites were broken initially, providing us with a concrete list of test suites to fix as part of marking an API compatible with Unified Grid."
  • Migration docs — the patterns that recur across broken tests (permission-check needs org-level check, routing needs workspace parameter) become the canonical migration guide.

Why not fork the test corpus?

Forking the corpus and writing new tests for the new architecture is tempting but:

  • Doubles the maintenance cost — every test change has to land in both corpora.
  • Loses coverage that the original tests encoded — the original tests' failure modes are the edge cases the new corpus would have to re-discover.
  • Makes cutover ambiguous — there's no single "all green" target; there are two corpora, with unclear relative authority.

The context-swap reuse approach gives you one canonical corpus that must pass under both contexts — during the migration, pass under workspace context (customers on the old path) and pass under org context (employees on the new path).

When the pattern pays off

  • The re-architecture is a context-axis change, not a functional redesign. If the APIs' behaviour is fundamentally different (not just their context), you can't share the test corpus; you have to write new tests.
  • Integration tests are parameterised by context at setup time. If context is hardcoded throughout the test corpus, the parameterisation work itself is large. The retrofit is still usually cheaper than re-writing.
  • The test corpus is already comprehensive. If tests are sparse, the signal from broken tests is noisy.
  • There is a clear migration ordering. The broken-test list only helps if you can associate each failure with an API and drive it to green.

When the pattern is wrong

  • Functional redesign of APIs. If APIs change semantics, not just context, the old tests' expectations are wrong under the new architecture.
  • Context is not a test-parameterisable input. If context is woven into test fixtures in a way that can't be swapped, the retrofit cost exceeds the rewrite cost.
  • The corpus is not trusted. If the tests are flaky or subjective, broken tests don't localise real failures.

Generalisation

The pattern appears in any re-architecture that changes a shared parameter across a test corpus:

  • Single-tenant → multi-tenant. Re-run single-tenant tests inside a tenant-aware wrapper.
  • Single-region → multi-region. Re-run single-region tests under region-parameterised setup.
  • Sync API → async API. Re-run sync flows inside an async-resolution wrapper.
  • v1 → v2 API. Re-run v1 tests against a v2-compatibility shim; broken ones are the migration backlog.
  • Single-shard → sharded. Re-run tests with the shard key parameterised.

The meta-pattern: axis-swap your existing integration tests rather than rewriting them. Broken tests become the migration backlog.

Seen in

Last updated · 470 distilled / 1,213 read