Shared Detection Module Isolation & Test Pre-Seeding

Overview

Rippling's application surface is large enough that module boundaries become operating constraints, not just code style. This work had two related problems: a shared detection package was too entangled with other teams' imports, and Automated Compliance tests were spending too much time building fragile state before the actual assertion.

I worked on both loops: architecture hygiene for the shared detection package and test pre-seeding for Automated Compliance. The shared pattern was boundary work: detection imports became explicit in the module-isolation work, and test setup started from valid product states in pre-seeding.

What I built

I worked with a staff engineer to decouple a shared detection package from tight cross-team imports. We moved product-specific dependencies behind explicit dependency interfaces so the shared package could pass module-boundary checks again and evolve without dragging unrelated product code behind it.

The payoff was practical: the domain code became easier to exercise without loading large unrelated parts of the application. Engineers could change detection logic with fewer unrelated imports, fewer surprise boot paths, and a clearer place to put integration-specific code.

I also wrote the dependency-injection documentation for the codebase so the pattern would survive the next feature and stay understandable to the next engineer working in the package.

Pre-seeding

Separately, I introduced a pre-seeding framework for Automated Compliance V1. The old CRUD-heavy setup created temporary companies through side-effect-heavy paths. Those companies often represented unsupported intermediate states, like an app installed before onboarding.

Pre-seeding replaced that with explicit, reusable fixture states for partner-company, subscription, and app-combination paths the product actually supports. It also removed invalid intermediate states from affected suites. There was a tradeoff, because pre-seeding has its own setup cost, but it moved repeated setup cost out of affected suites and into a controlled place.

Collaboration

The staff engineer helped settle the module-isolation pattern, while I moved the product-specific imports behind the dependency interfaces and documented the rule for the next feature.

Outcome

• The shared detection package no longer depended directly on cross-team product imports.
• Automated Compliance tests started from valid preseeded company states instead of improvised temporary state.
• Local and CI feedback loops had fewer invalid setup paths to reason through, especially around viewset-heavy tests.

The faster feedback loop came from making the boundaries explicit. Detection dependencies became visible, fixture states represented supported product paths, and engineers had less hidden setup to reason through before trusting a test.