ID

b6b3b53f-22a9-4c51-abd1-4faaa1d84c58

BE-7136 Add experiment enrollment filter to CustomerSearchView in test automation

- source :: https://hungryroot.atlassian.net/browse/BE-7136

- tags :: Hungryroot API Project

- epic :: EP-411 Eng Parking Lot

- sprint :: HR BE Sprint 104

- status :: Status - To Do

Description

Update the CustomerSearchView test automation endpoint to support filtering

customers by experiment ID and variant, enabling test automation to locate

customers enrolled in specific experiments and/or specific variant groups.

Background

The CustomerSearchView (test_automation/views/customer_search.py) currently

supports filtering by delivered orders count, customer status, preferred

delivery date, and ratable order status.

Test automation frequently needs to find customers enrolled in a particular

experiment (and optionally a specific variant) to validate experiment-gated

behavior. Today this requires manual database queries or hardcoded customer IDs

in test fixtures, which is fragile and difficult to maintain as experiments

change.

Data Model Context

Experiment enrollment is stored in the CustomerExperiment through model:

CustomerExperiment.customer -- FK to Customer (related name:

enrolled_experiments)

CustomerExperiment.experiment -- FK to Experiment (related name:

enrolled_customers)

CustomerExperiment.variant -- SmallIntegerField (0 = control, >0 = treatment

variants)

The Experiment model uses an integer primary key (4-digit convention XXYY) and

also has a string name field.

Experiments are commonly referenced by string ref like "exp_174" in application

code, but the underlying ID is an integer.

Requirements

Add two new filters to CustomerSearchFilter:

Filter

Type

Description

experiment_id

NumberFilter

Filter customers enrolled in the given experiment (by Experiment.id). Required

for the experiment filter to apply.

experiment_variant

NumberFilter

(Optional) Further filter to customers with a specific variant value. If

omitted, returns all customers enrolled in the experiment regardless of variant.

Example queries

?experiment_id=174 -- customers enrolled in experiment 174 (any variant)

?experiment_id=174&experiment_variant=0 -- customers in experiment 174, control

group

?experiment_id=174&experiment_variant=1 -- customers in experiment 174,

treatment variant 1

?experiment_id=174&status=active -- active customers enrolled in experiment 174

Implementation Notes

Add the filters using custom method functions on CustomerSearchFilter, following

the existing patterns (e.g., filter_status).

Filter through the enrolled_experiments reverse relation:

enrolled_experiments__experiment_id and enrolled_experiments__variant.

experiment_variant should only be applied when experiment_id is also provided.

If experiment_variant is supplied without experiment_id, it should be ignored or

return a validation error.

Consider handling both filters together in filter_queryset() (similar to

preferred_date + is_ratable) to ensure they apply to the same CustomerExperiment

row, avoiding incorrect cross-joins.

Add .distinct() since the join through enrolled_experiments can produce

duplicates.

Acceptance Criteria

[ ] GET /test-automation/customer-search/?experiment_id=174 returns only customers

enrolled in experiment 174

[ ] GET /test-automation/customer-search/?experiment_id=174&experiment_variant=1

returns only customers in experiment 174 with variant 1

[ ] experiment_variant without experiment_id is safely ignored or returns a

validation error

[ ] Existing filters continue to work and can be combined with the new

experiment filters

[ ] .distinct() is applied to prevent duplicate results from the join

[ ] Tests cover: experiment-only filter, experiment + variant filter,

variant-without-experiment edge case, and combination with existing filters