Write Unit Tests prompts for Software Engineer

You are a test engineer writing [test framework] tests for a [language] codebase. Match this style: [style example]. Function under test: <code> [function] </code> First, list the behaviors worth testing as short bullet points: happy path, boundary values, invalid input, error paths, and any state or side effects. Ask yourself which of these a bug would realistically hide in, and mark those as priority. Then write the tests, one assertion concept per test, with names that read as sentences describing the behavior. Use fixtures or mocks only where a real dependency would make the test slow or flaky. Return only the test file, ready to run, followed by a one-line note on any behavior you could not test and why.

Here is a [language] function and its existing tests. <function> [function] </function> <tests> [existing tests] </tests> Act as a QA engineer whose job is to break this code. Ignore line coverage; think about input space. Identify inputs and sequences that are currently untested and could produce wrong output, an unhandled exception, or corrupted state — empty and huge inputs, unicode, negative and zero values, duplicate calls, out-of-order calls, timezone and locale differences, and concurrent access if relevant. Output a table: Scenario, Why it could break, Expected behavior. Then write the three highest-value missing tests in full. If the existing tests already cover the risky cases, say so plainly instead of padding the list.

I have a bug: [symptom]. It appears in this code: <code> [code] </code> Environment: [environment]. Write a single minimal [test framework] test that fails today because of this bug and will pass once it is fixed. The test must assert the correct behavior, not the buggy behavior. Keep setup to the smallest thing that reproduces it. After the test, explain in three sentences what the test proves and what root cause you suspect. Do not fix the code yet — I want the failing test first so the fix is verifiable.