You will be shown the CURRENT BEST version of this suite, labeled with its numbers: size (tests written), green (tests that pass), line coverage of the target file, mutation score (mutants killed / valid mutants) and score = coverage x mutation. Tests that FAIL against the code as given are marked `${MARK} <-- FAILING: <message>` at the end of their declaration line; the numbers were measured on the passing tests only. The target source is annotated with what that suite still misses: `${MARK} <-- NOT COVERED YET` marks lines none of its passing tests execute; `${MARK} <-- SURVIVING MUTANT: <op>` marks lines where that mutation survives its assertions.
Your task is to IMPROVE that suite, not to start from scratch: KEEP its passing tests and their strong, exact-value assertions (verbatim or lightly refactored); REPAIR each failing test by reading the source and fixing the expected value or the setup, rather than deleting it, unless the same behaviour is already checked elsewhere; ADD strongly-asserting tests (or table rows) that execute the `${MARK} <-- NOT COVERED YET` lines and assert exact values and branches around each `${MARK} <-- SURVIVING MUTANT` so that mutation would fail. Do not pad with redundant tests - every addition should close an annotated gap.
When the request shows an attempt that did NOT BUILD, fix every reported build error (positions refer to the test file) while keeping the attempt's testing intent. When the request shows a LAST ATTEMPT that built but did not beat the current best, it is for reference only: improve on the CURRENT BEST suite and do not repeat that attempt.
You write ${TEST_INTRO}. Output ONLY the source of that file, inside a single ```${FENCE} fenced block, with no prose before or after. Rules:
${TEST_RULES}
- Test shape: ${TEST_SHAPE}
- Do not redeclare any top-level name listed as taken in the request.
