ID

facd89f5-c976-429b-9661-77806d0b1c62

BE-7351 Add original_points nullability support to CreateTestCustomerView for edge-case testing

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

- tags :: Hungryroot API Project

- epic :: EP-411 Eng Parking Lot

- sprint :: HR BE Sprint 106

- status :: Status - Complete

Tasks

DONE Add nullability support to the create test user endpoint for original_points

ID

5500fab3-a26d-bcb8-29da-6f8e955d49f6

Description

The CreateTestCustomerView in test_automation/views/create_test_customer.py

creates test customers with configurable settings for QA. Delivered orders are

created via DeliveredOrderFactory with with_box_contents, which fills order

details through BoxContentFactory.fill_box(). In this flow,

OrderDetail.original_points is always populated from product.points.

However, in production, original_points is a nullable DecimalField on

OrderDetail (app/models/order_detail.py:63) and real users can have null values.

Code that reads original_points (e.g. discount_percentage,

points_after_discount, swap/short logging in Order) may behave differently when

original_points is null vs populated. Our test data never reflects this edge

case.

Problem

All test-generated orders have original_points set on every OrderDetail, which

doesn't reflect the variety seen in production. It is unrealistic to manually

test every optional/nullable property, and there is currently no mechanism in

the test endpoint to generate data that exercises these edge cases.

Proposed Implementation

Two complementary approaches:

1. Direct original_points control

Add an optional nullify_original_points boolean (default false) to the

serializer. When true, after delivered orders are created, set original_points =

None on some or all OrderDetail rows for that customer's orders. This gives

testers a direct toggle to reproduce the production edge case.

2. Broader "edge case mode" (stretch goal)

Consider a more general edge_case_mode or nullify_fields parameter that randomly

nullifies optional/nullable fields on generated test data to better simulate

real-world variety. This would be a more scalable solution for catching

null-safety issues across many fields, not just original_points. This could be

scoped as a follow-up ticket if the direct approach above is sufficient for now.

Relevant Code

OrderDetail.original_points - app/models/order_detail.py:63 (nullable DecimalField)

OrderDetail.discount_percentage - reads original_points, will error if null (app/models/order_detail.py:94-98)

OrderDetail.points_after_discount - reads original_points (app/models/order_detail.py:101-109)

Order swap/short logging - serializes original_points with null checks (app/models/order.py:2680, 2722, 2749)

DeliveredOrderFactory + BoxContentFactory - always populates original_points from product.points

create_delivered_orders_for_test_customer task - test_automation/tasks.py

Acceptance Criteria

+ [ ] New optional boolean field (e.g. nullify_original_points) added to TestCustomerCreationSerializer

+ [ ] When enabled, delivered orders are created with original_points = None on their OrderDetail rows

+ [ ] Default behavior (field omitted or false) is unchanged - original_points is populated normally

+ [ ] Field is documented in API schema via help_text

+ [ ] Unit tests cover both the default and nullified scenarios