What they're testing
Whether you think in equivalence classes and boundary values, or only test what you just wrote.
The short answer~30 seconds
I start by listing input CLASSES rather than values: empty order, one item, many items, with a discount code, an expired code, quantity zero, negative quantity, zero price. Then boundary values around each business threshold — if free shipping starts at 500k, test 499,999, 500,000 and 500,001. And one property-style test: the total is never negative, whatever the input.
The long answer
Boundaries are where bugs concentrate because that's where a developer chooses between < and <=, and both compile. A test at 400k and one at 600k pass under either; only a test exactly at 500,000 distinguishes them. Which is why a large suite with arbitrarily chosen values can still miss most real bugs.
Property-based testing is worth raising because it finds combinations nobody thinks of: you declare a property ("applying a discount never increases the total") and the library generates thousands of random inputs, then shrinks any failure to its minimal form. For pricing logic with overlapping rules it's very effective, and it complements rather than replaces example-based tests.
What they'll ask next
?Is TDD mandatory?
No, but it's most useful in exactly this kind of problem: writing the test first forces you to define behaviour at the boundaries BEFORE implementing, so you're less anchored by the code you just wrote. For exploratory design I'm more flexible; for business logic with explicit rules, test-first is almost always faster.
These lose points
- Testing only the happy path. That's a test proving you ran the code once.
- Reimplementing the formula in the test. If the formula is wrong the test is wrong the same way, and it catches nothing.