[Improvement] Enhance test error messages in CLI tests

Resolved 💬 0 comments Opened Feb 10, 2026 by hobostay Closed Feb 14, 2026

Summary

The test code in codex-rs/cli/src/main.rs uses generic panic! messages that could be improved to provide better debugging information when tests fail.

Problem Description

Currently, several tests in the CLI module use generic panic messages like:

  • "expected exec subcommand"
  • "expected exec resume"
  • "expected features enable"

When these tests fail, the panic message doesn't provide enough context about what was actually received, making debugging more difficult.

Location: codex-rs/cli/src/main.rs

  • Lines 1099, 1102, 1390, 1393, 1403, 1406

Example

// Current implementation
let Some(Subcommand::Exec(exec)) = cli.subcommand else {
    panic!("expected exec subcommand");
};

// Suggested improvement
let Some(Subcommand::Exec(exec)) = cli.subcommand else {
    panic!("expected exec subcommand, got: {:?}", cli.subcommand);
};

Suggested Improvement

Include the actual value in the panic message to provide debugging context:

panic!("expected exec subcommand, got: {:?}", cli.subcommand);

Or even better, use unreachable!() since these paths should theoretically never be reached (the else branch on a Some pattern match that should always succeed):

let Some(Subcommand::Exec(exec)) = cli.subcommand else {
    unreachable!("expected exec subcommand, got: {:?}", cli.subcommand);
};

Impact

  • Priority: Low
  • Severity: Quality of life improvement
  • Risk: Very low - only affects test code

Benefits

  • Faster debugging when tests fail
  • Clearer error messages in CI/CD logs
  • Better developer experience for contributors

Additional Context

This is a minor code quality improvement that would help with test maintenance and debugging. The tests themselves are correct, only the error messages need enhancement.

---
Note: I'm aware that external PRs are by invitation only. I'm submitting this issue to contribute analysis and suggestions as outlined in the contributing guidelines.

View original on GitHub ↗