Can rspec preserve seed state across infrequent test runs without manual intervention?

No, RSpec cannot preserve seed state across infrequent test runs without manual intervention. The --seed flag is a per-invocation input; RSpec does not write the seed used in a previous run to a file or metadata store to be automatically retrieved during subsequent executions.

How RSpec Handles Seeds

By default, when you run RSpec without a specified seed, the framework generates a random integer for that specific process. This seed is printed in the output (e.g., Randomized with seed 12345), allowing a developer to manually reproduce a specific failure order by passing that number back into the next run via --seed 12345.

Behavior Across Versions

While RSpec 3.x and 4.x both support the --seed flag for reproducibility, neither version implements internal state persistence between runs. In dormant CI pipelines or sporadic manual runs, every single invocation is treated as a fresh start. If no seed is provided, a new one is generated. Any perceived persistence in a CI environment is likely the result of an external wrapper, a committed .rspec configuration file, or a CI cache storing the command string, rather than a feature of RSpec itself.

Achieving Determinism Without Manual Input

To ensure the same test order across gaps in execution without manually typing the seed each time, you must move the seed from a command-line argument to a persistent configuration:

• The .rspec File: Add --seed 12345 to your .rspec file in the project root. This ensures every run uses the same seed until the file is modified.
• CI Configuration: Hardcode the seed in your CI YAML or pipeline definition (e.g., bundle exec rspec --seed 12345).

Verification and Constraints

You can verify that a seed is being honored by running the following sequence:

# Run once with a fixed seed
bundle exec rspec --seed 4242

# Run again with the same seed
bundle exec rspec --seed 4242

If the execution order of examples is identical, the seed is functioning. If you run the command twice without the flag, you will see different seeds in the output, confirming that no automatic persistence exists.

Important Limitations

• Ordering vs. State: A fixed seed only controls the order of examples. It does not make application-level randomness (e.g., SecureRandom), timestamps, or database state deterministic.
• Order Configuration: If your spec_helper.rb contains config.order = :defined, the --seed flag will be ignored because the suite is instructed to follow the file definition order.

Diagnostic Detail Needed: To provide a more specific configuration recommendation, please provide the exact version of rspec-core listed in your Gemfile.lock.