What makes a unit test useful?
Choose a clear behavior, controlled inputs, and an observable expected result. A test should fail when that behavior breaks and provide enough context to locate the problem. Whether the unit is a function or a small component depends on the design.
For a delivery-fee function, test the business boundary rather than how many private helper functions it calls. Refactoring an internal helper should not force unrelated tests to change if the externally meaningful behavior remains correct.
How do you choose edge cases?
Partition inputs by rules, then test boundaries and representative cases. Our sample policy charges 50 for orders below 500 and zero at or above 500, with negative order amounts rejected. Useful inputs include 0, 499, 500, and a negative amount.
Specify the numeric unit and valid type. If the amount is represented in minor currency units, the threshold must use the same unit. A mathematically correct comparison using inconsistent units is still a business defect. Tests should make that assumption visible.
When should you mock a dependency?
Mock when you need a controlled substitute for a boundary such as a clock or external service. Keep assertions focused on the contract that matters. Over-mocking internal collaborators can make tests pass while the real components no longer work together.
If a delivery quote depends on a remote carrier, unit tests can exercise success and timeout handling using a substitute. Retain an appropriate integration check for the actual request and response contract. A mock returning an invented shape cannot establish compatibility with the real service.
Does high coverage prove correctness?
Coverage describes exercised code, not the strength of the assertions or completeness of requirements. A test that calls a function and checks nothing can execute many lines. Use coverage to find unexamined paths, then evaluate whether important behavior is meaningfully asserted.
Determinism also matters. Inject a clock or controlled random source when the behavior depends on time or randomness. Avoid a test that passes only before midnight or only with the developer's timezone. State which environment assumptions the test owns.
Practice exercise
Write expected results for delivery fees at 0, 499, 500, and 501, plus rejection for a negative amount. Change the implementation's threshold comparison from greater-than-or-equal to greater-than and identify the test that must fail.
Next, add a loyalty exemption. Test the interaction between loyalty and invalid input, and decide which rule wins. This is a requirements question before it is a testing-framework question. Keep the expected results explicit.
Rehearse this answer with Cluegent
Use Cluegent to propose a mutation that should break your delivery-fee tests. Check whether the suite catches it, then explain any uncovered rule in your own words.
Try Cluegent for your practice session, then repeat the explanation without suggestions. Judge your answer by its accuracy, evidence, and response to follow-up questions.
Sources checked
These official references support the guide. Product details and technical documentation can change; check the linked source for current information.
Where Cluegent helps
Cluegent supports permitted live workflows with transcript context, typed prompts, screenshot-aware answers, resume context, custom response behavior, quick action buttons, and a private desktop overlay. It is most useful when you already understand the subject and need help staying structured under pressure.
Frequently asked questions
How should I practise this topic?
Write expected results for delivery fees at 0, 499, 500, and 501, plus rejection for a negative amount. Change the implementation's threshold comparison from greater-than-or-equal to greater-than and identify the test that must fail.
How can Cluegent help with preparation?
Use Cluegent to propose a mutation that should break your delivery-fee tests. Check whether the suite catches it, then explain any uncovered rule in your own words.