-
Notifications
You must be signed in to change notification settings - Fork 90
Designing an experiment
Because Enabled and RunIf determine when a candidate runs, it's impossible to guarantee that it will run every time. For this reason, Scientist is only safe for wrapping methods that aren't changing data.
When using Scientist, we've found it most useful to modify both the existing and new systems simultaneously anywhere writes happen, and verify the results at read time with Science. ThrowOnMismatches has also been useful to ensure that the correct data was written during tests, and reviewing published mismatches has helped us find any situations we overlooked with our production data at runtime. When writing to and reading from two systems, it's also useful to write some data reconciliation scripts to verify and clean up production data alongside any running experiments.
- Publishing results
- Controlling comparison
- Adding context
- Expensive setup
- Keeping it clean
- Ignoring mismatches
- Enabling or disabling experiments
- Ramping up experiments
- Running candidates in parallel (asynchronous)
- Testing
- Handling errors
- Designing an experiment
- Finishing an experiment
Sometimes scientists just gotta do weird stuff. We understand.