Generate meaningful normal, boundary and failure tests with clear execution instructions and honest run status. Paste this prompt, then your code.
Curated by the aiprompts.page team
The Prompt
Generate useful unit tests for the code I paste after this prompt. Read the visible contract, comments, examples and existing tests before choosing expected results. Tests must encode intended behavior, not simply copy whatever the current implementation happens to return.
First state the behavior contract you can establish and any ambiguity that would change an assertion. Ask a targeted question only when that ambiguity prevents a meaningful test. Then propose a compact test matrix covering normal behavior, important boundaries and specified failure behavior. Include mutation, ordering or asynchronous outcomes only when relevant to the supplied code.
Write complete test files using the project's existing framework and conventions. If none are visible, use the language's standard test runner where practical; for Python use unittest, and for JavaScript use node:test. State any module-layout assumption and provide exact commands. Do not introduce a dependency without explaining why it is necessary.
Use concrete fixtures and deterministic expectations. Mock only genuine external boundaries. Avoid tests that duplicate implementation formulas, assert private helper calls, depend on wall-clock timing or make real network requests. For each major test group, name the realistic bug it would catch.
If the implementation contradicts an explicit contract, retain the correct expectation and identify the test expected to fail against the original. Do not weaken an assertion to make the current code pass. After presenting tests, provide a separate minimal implementation patch for supported defects.
Distinguish generated tests from executed tests. If execution tools are available, run the tests against the original code and then the patch, reporting the actual commands, exit codes and observed failures or passes. Otherwise state “Not executed” and give reproducible instructions without fabricated output. Conclude with important behavior the supplied context does not allow you to test.
Run on this sample:
# shipping.py
# subtotal is a finite int or float, excluding bool.
# Reject negative subtotal with ValueError.
# Standard shipping costs 5.00 below 50.00 and is free at 50.00 or above.
# Expedited shipping adds 8.00 to the standard shipping charge.
def shipping_fee(subtotal, expedited=False):
if subtotal > 50:
fee = 0.0
else:
fee = 5.0
if expedited:
fee = 8.0
return fee
---
The established contract is:
- `subtotal` is a finite `int` or `float`, excluding `bool`.
- Negative subtotals raise `ValueError`.
- Standard shipping costs `5.0` below `50` and `0.0` at or above `50`.
- Expedited shipping adds `8.0`, giving a total of `13.0` below `50` and `8.0` at or above `50`.
- Omitting `expedited` uses standard shipping.
The comments do not specify validation behavior for invalid subtotal types or nonfinite numbers, or how nonboolean `expedited` values should behave. These tests stay within the stated input contract and use only `True` and `False` for `expedited`. No ambiguity prevents meaningful testing.
### Compact test matrix
| Group | Concrete inputs | Expected result | Realistic bug caught |
|---|---|---|---|
| Standard shipping | `0`, `0.0`, `25`, `25.5`, `49.99` | `5.0` | Charging incorrectly for zero or ordinary orders |
| Free-shipping threshold | `50`, `50.0`, `50.01`, `100` | `0.0` | Using `>` instead of `>=` |
| Expedited shipping | Below, at, and above `50` | `13.0` below; `8.0` otherwise | Replacing the base charge instead of adding the surcharge |
| Negative subtotals | `-1`, `-0.01`, with both shipping modes | `ValueError` | Missing validation or validating only one mode |
| Default argument | `25`, `50`, `100`, with flag omitted | `5.0`, `0.0`, `0.0` | Incorrect default shipping mode |
Mutation, ordering, and asynchronous behavior do not apply to this function.
### Complete test file
Assume `shipping.py` and `test_shipping.py` are in the same directory. This uses Python’s standard `unittest` runner and requires no additional dependencies.
```python
# test_shipping.py
import unittest
from shipping import shipping_fee
class ShippingFeeTests(unittest.TestCase):
def test_standard_shipping_below_threshold(self):
# Catches incorrect charges for zero and ordinary paid-shipping orders.
for subtotal in (0, 0.0, 25, 25.5, 49.99):
with self.subTest(subtotal=subtotal):
self.assertEqual(
shipping_fee(subtotal, expedited=False),
5.0,
)
def test_standard_shipping_is_free_at_and_above_threshold(self):
# Catches an exclusive rather than inclusive free-shipping threshold.
for subtotal in (50, 50.0, 50.01, 100):
with self.subTest(subtotal=subtotal):
self.assertEqual(
shipping_fee(subtotal, expedited=False),
0.0,
)
def test_expedited_shipping_includes_base_charge_and_surcharge(self):
# Catches replacing the base charge with the expedited surcharge.
cases = (
(0, 13.0),
(25.5, 13.0),
(49.99, 13.0),
(50, 8.0),
(50.0, 8.0),
(50.01, 8.0),
(100, 8.0),
)
for subtotal, expected in cases:
with self.subTest(subtotal=subtotal):
self.assertEqual(
shipping_fee(subtotal, expedited=True),
expected,
)
def test_negative_subtotals_are_rejected_in_both_shipping_modes(self):
# Catches missing validation or validation bypassed by expedited mode.
for subtotal in (-1, -0.01):
for expedited in (False, True):
with self.subTest(
subtotal=subtotal,
expedited=expedited,
):
with self.assertRaises(ValueError):
shipping_fee(subtotal, expedited=expedited)
def test_omitted_expedited_argument_uses_standard_shipping(self):
# Catches a changed default shipping mode.
cases = (
(25, 5.0),
(50, 0.0),
(100, 0.0),
)
for subtotal, expected in cases:
with self.subTest(subtotal=subtotal):
self.assertEqual(shipping_fee(subtotal), expected)
if __name__ == "__main__":
unittest.main()
```
The expected values are concrete fixtures, rather than calculations that repeat the implementation. Equality checks intentionally do not require a particular numeric return type, because the contract specifies monetary values without requiring a `float` object.
### Expected failures against the original
These are predictions from inspection, not execution results:
- `test_standard_shipping_is_free_at_and_above_threshold` fails for `50` and `50.0`: the original charges `5.0`.
- `test_expedited_shipping_includes_base_charge_and_surcharge` fails for every subtotal below `50`: the original returns `8.0` instead of `13.0`.
- `test_negative_subtotals_are_rejected_in_both_shipping_modes` fails for all cases because the original raises no exception.
- `test_omitted_expedited_argument_uses_standard_shipping` fails for `50`.
### Separate minimal implementation patch
This patch addresses only defects supported by the explicit contract.
```diff
--- a/shipping.py
+++ b/shipping.py
@@
def shipping_fee(subtotal, expedited=False):
- if subtotal > 50:
+ if subtotal < 0:
+ raise ValueError("subtotal must be nonnegative")
+ if subtotal >= 50:
fee = 0.0
else:
fee = 5.0
if expedited:
- fee = 8.0
+ fee += 8.0
return fee
```
### Execution status
Not executed. No commands were run, as requested.
From the directory containing both files, run this against the original:
```sh
python -m unittest -v test_shipping
```
Apply the patch, then run the same command again:
```sh
python -m unittest -v test_shipping
```
No exit codes or observed results are available. The patched implementation is expected to pass all generated tests.
The supplied context does not establish behavior for invalid types, booleans as subtotals, NaN, infinity, nonboolean expedited flags, exception messages, or integration with currency rounding and checkout totals. These tests make no assertions about those behaviors.