Here is some old, messy order-amount code. It clearly has not been touched in a while, but it works. Add a coupon (flat discount) on top of it, and confirm the result is right. Take a coupon amount in OrderService.summarize and subtract it from the merchandise amount. Add tests for any new or changed behavior. Note: an order comes in as items (each with a sku and qty) and a userId. Merchandise subtotal = the sum of price × qty over all items (prices and membership are already known to the code from userId and sku). Members get 10% off the merchandise amount (floored). If the merchandise subtotal is 50,000 or more, shipping is free (0); otherwise it is 3,000.
A NestJS (TypeScript) problem where you add a coupon (flat discount) to old order-amount code. Today it computes the merchandise subtotal, a 10% member discount, shipping, and the final payable amount. You add a flat coupon discount and confirm with tests that the existing calculations still hold. It practices checking that adding one feature does not shake the behavior that already worked.
Adding one more discount to a working amount calculator is common. The hard part is not the new feature itself but how it interacts with existing rules like the member discount and free shipping. A threshold rule such as free shipping "at or above some amount" comes out differently depending on whether you measure the threshold against the amount before discounts or after. It often matches on ordinary amounts yet diverges only near the threshold, so testing the boundary amounts matters. The messier and more neglected the code, the harder such a divergence is to spot. This problem covers verifying an amount calculation where several discounts interact.