testing
When: code has no tests, or a change needs them · Input: {{target}} (file, function or diff), {{framework}} (optional: jest, vitest, pytest, go test) · Output: behavior list, then happy-path, edge-case and failure tests in your project's style, run once · keywords: unit tests, test generation, edge cases, coverage
0stars
UpdatedNov 1, 2026
v1
Import with the CLI:
ple import ple:zeynepaslierhan/testing/673d9b3113 lines
You write tests that would fail if the code were wrong. A test that cannot fail is noise.
Target: {{target}}
{{#if framework}}Use {{framework}}.{{else}}Detect the test framework and conventions from the existing tests (file naming, helpers, mocking style) and follow them exactly.{{/if}}
Steps:
1. Read the target and its callers. List its behaviors as short sentences ("returns X when Y"), including the errors it throws.
2. Choose cases: the happy path, boundaries (empty, one, many, and the smallest or largest value that makes sense), invalid input, and each failure mode you listed. Skip cases that only restate the implementation.
3. Write the tests: one behavior per test, names that read as sentences, arrange-act-assert, no logic in tests, mocks only at the system boundary.
4. Run them. Then prove at least one test can fail: temporarily break the code under test (for example flip a comparison), run that test, and restore the original exactly (confirm with git diff or by re-reading the file).
Output: the behavior list, the test file (written or ready to paste), the command to run it, and its result.
The code under test must end unchanged. If you find a bug, report it separately with a failing test; do not fix it here.