Coding & Software
Write Unit Tests for a Function
Generates focused unit tests for one function, covering normal cases, boundaries and invalid input without mocking more than needed.
- Customizable fields
- 3 fields
Coding & Software
Plans a refactor as small reversible steps, states the behavior to preserve and says what to test before each step.
Designed for general-purpose AI assistantsPublished November 2026
Fill in the fields and the prompt updates. What you type stays in this page and is never saved or sent.
Help me refactor the code below without changing what it does.
Language: {{language}}
What is wrong with it today: hard to read and hard to test
Behavior that must not change: {{behavior to preserve}}
Existing tests: none
Things I do not want touched: public function signatures
Code:
{{code}}
Before proposing anything:
- Restate, in your own words, the behavior that must be preserved, including edge cases visible in the code (empty input, errors, ordering, rounding).
- If an edge case could be a bug rather than intended behavior, list it and ask me whether to preserve it. Do not decide for me.
Then give me:
1. A refactoring plan of at most 5 steps. Each step must be small enough to commit on its own and must say what changes, why, and which behavior it could affect.
2. For each step, one check I can run (a test, a command or a manual comparison) that would catch a regression.
3. The refactored code after the final step.
4. A list of anything you deliberately left alone and why.
Rules: no new features, no renamed public interfaces unless I allowed it, no new dependencies, and no clever rewrite that cannot be reviewed line by line.3 required fields are empty and will stay as a {{placeholder}} in the copied text.
Illustrative only. Real answers depend on your input and the assistant you use.
Behavior to preserve: calculate_total returns 0 for an empty cart, rounds each line to two decimals before summing, and applies the discount only if the subtotal is at least 50. Question before I continue: the code applies the discount after rounding, so 49.996 becomes 50.00 and qualifies. Is that intended? I will preserve it unless you say otherwise. Plan: 1. Extract line_total(item) from the loop. Affects: rounding. Check: test that 3 items at 9.995 sum to the same total before and after. 2. Extract qualifies_for_discount(subtotal). Affects: the threshold comparison. Check: subtotal exactly 50.00 still qualifies. 3. Replace the nested if with an early return for the empty cart. Affects: the empty-cart path. Check: empty cart returns 0. Left alone: the global TAX_RATE read, because changing it would alter how tests set up state. It deserves its own change.
A refactor that changes behavior is a rewrite. The "behavior that must not change" field exists to make you write that sentence down before the assistant does.
If the assistant proposes more steps than you asked for, treat that as a sign the code is doing too much and split the work across several sessions.
Keep the diff for each step small enough to review. If you cannot say in one sentence what a step changed, ask the assistant to split it.
Coding & Software
Generates focused unit tests for one function, covering normal cases, boundaries and invalid input without mocking more than needed.
Coding & Software
A structured review prompt that checks correctness, failure handling, security and tests, and labels every finding by severity.
Coding & Software
Explains code you did not write at the level you ask for, tracing the data flow and flagging what it cannot tell from the snippet alone.