For some hairy stuff that require live data you can also reverse the practice: call both yet return the old one, and gather data in production before switching.
Obviously this does not work for side-effectful methods (beware of caches!).
Obviously this does not work for side-effectful methods (beware of caches!).
In most fields we have a sample of known input vectors, including edge cases, that map to known outputs. A unit test is enough to test these methods with different implementations.
Or consider when you're performing a database migration (on large databases) with 0 downtime. Typically this involves something like:
1. Dual Writing: Create 2 tables and write to both and keep them in sync (by duplicating new data, and back-filling old data)
2. Update read paths: Change all code to read from the new table, and validate that the data being read is consistent with the old table. You can use a library like Scientist [0] to validate that the reads are the same.
3. Update write paths: Change all code to write to the new table (and raise alerts if the old path is exercised)
4. Deleting old data: Remove code and data that relies on the old data model