Skip to content

Conversation

@davepacheco
Copy link
Collaborator

@davepacheco davepacheco commented Nov 25, 2025

This replaces nexus_test_utils::test_setup and nexus_test_utils::test_setup_with_config with a builder-style interface instead, updating all callers to use it. Most tests today do not need to customize anything and they use the nexus_test macro (also updated in this PR). The other callers here are either customizing the tokio environment (the update tests do this to adjust the number of worker threads for their test) or something about the control plane configuration (either the config file or other arguments passed to test_setup_with_config).

Previously, we had:

  • test_setup, which accepted a test name and a number of "extra" sled agents.
  • test_setup_with_config, which accepted these, plus a whole parsed Nexus config file and a bunch of other Rust properties (TLS certificate, sim-sled-agent simulation mode, etc.)

This was sort of a weird middle ground:

  • test_setup was supposed to be the simplest one for the stock defaults, but it still made you specify the number of extra sled agents.
  • test_setup_with_config lets you control everything, but had the usual problem of functions with lots of arguments:
    • it wasn't super easy to know what the values meant
    • almost everybody was using defaults for almost everything, but had to fill them all in explicitly
    • adding a new property to customize requires changing all callers

This fixes all of that by providing a builder whose defaults match what you used to get with #[nexus_test], but where you can customize any of these individually without worrying about any others. You don't have to specify anything when you want a default.

The real motivation for this change is that I want to add a new thing you can customize here (for the new debug dropbox) and I didn't want to keep adding new arguments to test_setup_with_config that everybody has to deal with.

Staged on top of #9445.

@davepacheco
Copy link
Collaborator Author

This is ready for review but I'm leaving it as "draft" so I don't merge it before landing the PR that it depends on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants