Shared Detection Module Isolation & Test Pre-Seeding

Overview

These were two projects where setup was getting in the way of engineering work. A shared detection package pulled in other teams' product code, while Automated Compliance tests spent too much time building fragile state before reaching the behavior they were meant to test.

I worked on separating the detection package from its product-specific dependencies and, separately, introducing reusable test states for Automated Compliance. Both required understanding what the code actually needed before changing how it was assembled.

Isolating the detection module

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 dependency-injection documentation so engineers adding features had a reference for where those dependencies belonged and how to supply them.

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 setup with reusable fixture states for the partner-company, subscription, and app-combination paths the product supported. The affected suites could start from a valid state instead of constructing one through unsupported intermediate steps. Pre-seeding still had its own setup cost; the benefit was paying for shared preparation instead of repeating that work throughout the affected suites.

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.

In both projects, understanding the setup was part of trusting the result. The dependency interfaces made it clearer what the detection code needed, while the fixtures made it clearer which product state a test was exercising.