remote-tests
Testing against remote executors in integration tests.
Works with
--- name: remote-tests description: Testing against remote executors in integration tests. license: Apache-2.0 --- Remote executor tests exercise the app-server/exec-server split to ensure that agent features work in both local and remote execution environments. Remote executor tests currently require an x86_64 Linux host machine. There are two flavors: 1. Docker (Linux exec-server) 2. Wine (Windows exec-server) ## Test Fixtures Individual test cases must opt-in to being run against a remote executor. ### codex_core Use `TestCodexBuilder::build_with_auto_env()` to opt-in to remote execution in core integration tests unless the test needs more precise control over its executor. ### app-server Start the server with `TestAppServer::new_with_auto_env()` unless the test defines its own `$CODEX_HOME/environments.toml` or will define custom environments at runtime. Start threads with `TestAppServer::send_thread_start_request_with_auto_env()` if you've created the server with the `auto_env` approach. Omit `ThreadStartParams.environments` (leave it as `None`) when doing so. ## Test Skips If a test doesn't pass in a particular remote executor configuration you can skip it in just that configuration. Include a string reason for future readers when the selected skip macro supports one. Choose the skip macro by what causes the test to fail: - `skip_if_target_windows!`: Windows target behavior. - `skip_if_wine_exec!`: Wine-exec runner constraints. - `skip_if_host_windows!`: Windows host constraints. - `skip_if_remote!`: Local-only test behavior. - `skip_if_no_remote_env!`: Remote-only test behavior. Prefer defining tests that run in all host/target configurations by default. See the `$path-types` skill for the most common changes required to make tests compatible. ## Docker Docker container is built and initialized via ./scripts/test-remote-env.sh. Sourcing this script in bash also provides the `codex_remote_env_cleanup` function to use after testing. To run core integration tests against a Docker remote executor: ```bash bash -c ' set -euo pipefail unset CODEX_TEST_REMOTE_EXEC_SERVER_URL source scripts/test-remote-env.sh trap codex_remote_env_cleanup EXIT cd codex-rs just test -p codex-core --test all ' ``` To run app-server integration tests against a Docker remote executor: ```bash bash -c ' set -euo pipefail unset CODEX_TEST_REMOTE_EXEC_SERVER_URL source scripts/test-remote-env.sh trap codex_remote_env_cleanup EXIT cd codex-rs just test -p codex-app-server --test all ' ``` ## Wine These tests build an exec-server for Windows and run it under Wine, with the app-server staying on the Linux host. The cross-platform build dependency means they only run in Bazel. For core integration tests: ```sh bazel test //codex-rs/core:core-all-wine-exec-test ``` For app-server integration tests: ```sh bazel test //codex-rs/app-server:app-server-all-wine-exec-test ``` ## Devboxes You can use a devbox to run these tests if you are running on a macOS machine. You can list devboxes via `applied_devbox ls`, pick the one with `codex` in the name. Connect to devbox via `ssh <devbox_name>`. Reuse the same checkout of codex in `~/code/codex`. Reset files if needed. Multiple checkouts take longer to build and take up more space. Check whether the SHA and modified files are in sync between remote and local.
More Testing skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
setup-pre-commit
mattpocock/skills
Set up Husky pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo. Use when user wants to add pre-commit hooks, set up Husky, configure lint-staged, or add commit-time formatting/typechecking/testing.
agent-browser
vercel-labs/agent-browser
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.

