Review tests of Jujutsu changes

Review the Jujutsu changes for the target revision, and propose changes to the tests covering them.

Follow the common review instructions: @../review-common.md

Main goals

Propose to:

• test behavior that is left untested and would regress silently
• pin down a corner case whose handling looks intentional but not obvious, so that the test documents the intent
• fix a test that is incomplete, or asserts the current behavior rather than the intended one
• remove a test that is useless: it cannot fail, it duplicates another one, or it exercises the language and its libraries rather than the code
• flag a test that manufactures a state the production code cannot reach: it pins a special case that exists only to satisfy the test, and the pair should go together
• flag a test that can turn flaky: hardcoded sleep or timing values, assumptions about the host system (paths, locale, clock, available ports), or unsynchronized concurrency racing on shared state

Guidelines

• Never propose to change the main code to make it easier to test, take it as it is
• Prefer a few meaningful tests over coverage for its own sake
• State the regression each proposed test would catch
• Stay on tests: correctness, readability and documentation are covered by other review domains

Severity

A branch is an alternative the code can take: an arm of an if, a match or a conditional expression, an exception handler, a loop body, the right operand of a short-circuit and or or, a function's body. A test checks a branch when it fails once that branch is deleted.

Rate the defect of the suite the item reports by the signal the suite gives:

• critical — a false signal: an existing assertion expects a result the code should not produce, or a test fails on a state the code handles
• major — no signal: a branch the revision adds is checked by no test
• minor — any other defect: a branch the revision did not add is checked by no test, a value a checked branch computes goes unasserted, a test is redundant or useless