0
Generate high-value unit tests for existing untested code, not filler
⁂auto-checked, 4 days oldAauraNovice
The prompt
Write unit tests for the function/class below in framework. I don't want boilerplate happy-path-only tests. For each test you write, briefly state (as a comment) what specific risk it guards against. Cover, in priority order:
1. Boundary conditions implied by the code (off-by-one ranges, empty collections, first/last element behavior).
2. Error paths: every raised exception or returned error should have at least one test that triggers it deliberately.
3. State mutation correctness if the function has side effects: assert the state after, not just the return value.
4. Any branch in the code that isn't exercised by the boundary/error tests above, so coverage isn't accidental.
5. Skip tests that would just restate the implementation (e.g. mocking every internal call so the test can't fail even if logic changes) - flag anywhere the code's structure makes it hard to test meaningfully without a refactor, instead of writing a fake test.
Code: code
Existing test file (if any, so I don't get duplicates): existing_tests
Where it has been run
| Model | Version | People | Broke | Auto | Last |
|---|---|---|---|---|---|
| Claude | Haiku 4.5 | 0 | 0 | 1/1 | 4 days ago |
Example output
```python
def test_empty_batch_returns_empty_result():
# guards against: off-by-one in the loop that could crash or return None on empty input
assert process_batch([]) == []
def test_single_negative_amount_raises_value_error():
# guards against: silently processing a negative refund amount as valid
with pytest.raises(ValueError, match="amount must be positive"):
process_batch([{"amount": -5}])
def test_partial_failure_leaves_successful_items_committed():
# guards against: an all-or-nothing rollback bug when only item 3 of 5 fails
result = process_batch([valid_item, valid_item, bad_item])
assert result.committed_count == 2
```
Flagged: `process_batch` calls `self._db.commit()` directly inside the loop, which makes it hard to test the partial-failure rollback behavior without a real or heavily mocked DB; a cleaner design would separate 'compute what to commit' from 'commit it', worth a small refactor before adding more tests here.
0 comments
Sign in to comment or report what this prompt did for you.
Sign inNo comments yet. Run the prompt and report what you got.