Test case
One named scenario: given these inputs and these steps, this exact result must come out. The smallest unit of 'we checked that'.
See it
What it is
A test case is one named scenario: given this starting state and these inputs, this exact result must come out. In code it is a single it() or test() block. In a QA document it is a row with preconditions, steps, and an expected result. Same idea either way, one claim about one behavior.
Good cases follow arrange-act-assert and are named after the behavior, not the function: 'rejects a coupon after its expiry date' tells you more from the CI log than 'test applyCoupon 3'. Cover the happy path first, then the edges that actually bite: empty, zero, negative, duplicate, too long, wrong type, already used.
Gotcha: stuffing five behaviors into one case. When it goes red you get one line of failure for five possible causes, and the first failed assertion hides everything after it. Split them. If the setup is repetitive, that is what fixtures and parameterized tests are for.
Ask AI for it
Write the test cases for the applyCoupon function as separate it() blocks in Vitest, one behavior each. Name every case in the form 'does X when Y'. Include the happy path plus expired coupon, already-redeemed coupon, unknown code, and zero-value cart. Structure each with arrange-act-assert and put shared setup in a beforeEach, not duplicated in every case.