Awesome Reviewers

Tests should be aligned with what they claim to validate, and placed at the right layer (unit vs integration). Concretely:

• Don’t rely on system side effects in unit tests. If the test depends on vmnet/network/kernel/fs behavior, prefer integration coverage; unit tests should focus on pure logic.
• Validate the real observable behavior. Avoid indirect checks that can miss regressions (e.g., a kernel-set test should confirm the running kernel via uname -r, not just that the command succeeded). For CLI/progress rendering, assert the actual emitted bytes (use a Pipe, read raw output, check \n vs \r, and ensure no extra lines).
• Make assertions match the intended semantics. Remove “weird” expectations and assert the specific resources that should change (e.g., prune should delete the volumes you created).
• Add boundary/edge-case coverage for pure logic. If a rule exists (like max container name length), add unit tests for the exact boundary.
• Improve robustness for filesystem/cleanup behavior. Use deterministic allocation (e.g., prefer /dev/urandom), add sync before/after, and assert on measurable effects rather than assuming timing.

Example pattern for meaningful terminal assertions:

func testPlainModeTerminalOutput() async throws {
    let pipe = Pipe()
    let config = try ProgressConfig(
        terminal: pipe.fileHandleForWriting,
        description: "Task",
        outputMode: .plain
    )
    let progress = ProgressBar(config: config)
    progress.render(force: true)
    progress.finish()
    try pipe.fileHandleForWriting.close()

    let data = pipe.fileHandleForReading.readDataToEndOfFile()
    let output = String(decoding: data, as: UTF8.self)
    #expect(output.components(separatedBy: "\n").count == 3) // exactly two lines
}

Apply the same idea to other “claim vs reality” gaps: if the test name implies a behavior, the assertions must directly observe it.

This site is open source. Improve this page.