test: faster test execution in codex-core

[nornagon-openai]

this dramatically improves time to run cargo test -p codex-core (~25x speedup).

before:

cargo test -p codex-core  35.96s user 68.63s system 19% cpu 8:49.80 total

after:

cargo test -p codex-core  5.51s user 8.16s system 63% cpu 21.407 total

both tests measured "hot", i.e. on a 2nd run with no filesystem changes, to exclude compile times.

approach inspired by Delete Cargo Integration Tests, we move all test cases in tests/ into a single suite in order to have a single binary, as there is significant overhead for each test binary executed, and because test execution is only parallelized with a single binary.

[bolinfest]

@nornagon-openai this is very exciting, but could you please update the PR body to explain the strategy/approach behind this?

[nornagon-openai]

@bolinfest done

[bolinfest]

@nornagon-openai thanks for the pointer: it's very helpful!

As per https://matklad.github.io/2021/02/27/delete-cargo-integration-tests.html, it would be nice to get rid of these:

codex-rs/core/tests/common
codex-rs/mcp-server/tests/common

but that can be done in a follow-up PR.

The article also mentions:

For an internal library, I avoid integration tests all together. Instead, I use Cargo unit tests for “integration” bits:

src/
  lib.rs
  tests.rs
  tests/
    foo.rs
    bar.rs

That way, I avoid linking the separate integration tests binary altogether. I also have access to non-pub API of the crate, which is often useful.

I think we should consider doing this for core at some point because core/src/lib.rs exposes a lot more than I think is healthy, and I think at least some of that was for the benefit of integration tests.

But again, can also be done in a follow-up.