In addition to the unit testing of individual components, we need some integration testing of the scenarios which we expect may have problems. Some ideas for things to test:

• Create several collections outside of a multi-document transaction. Advance the stable timestamp incrementally to each of the timestamps, take a checkpoint, and verify that the checkpoint contains only the expected tables.
• Create several collections inside of a multi-document transactions. Take a checkpoint without advancing the stable timestamp, then advance and take another checkpoint. Verify that each checkpoint contains the expected tables.
• Begin a multi-document transaction, create a collection, and then perform non-MDT writes. Verify that the stable timestamp can advance while the MDT is still active.
• Create a collection, drop the collection, and reap the tables all without taking a checkpoint. Advance the stable timestamp, and verify that the checkpoint does not contain the table.
• Create a collection, advance stable timestamp and checkpoint, drop the collection, advance stable timestamp and checkpoint, reap the table, checkpoint without advancing, advance stable timestamp and checkpoint again. Verify that checkpoints 1-3 have the table and checkpoint 4 does not.
• Create a collection but hang the creation process prior to publish() being called. Perform non-schema writes and verify that the stable timestamp cannot advance.
  Concurrently create multiple indexes on the same collection, producing spurious write conflicts and forcing the create to be retried. Verify that we can checkpoint afterwards. This would fail if we don't handle rollback properly.
• Drop collections, then have another node step up while they are drop-pending. Verify that the tables are dropped by the new primary.
• Create a stuck read on a secondary, then drop collection on primary. Verify that the replicated dropTable fails correctly.

Some of these may already be covered by existing tests and there are probably other things worth testing as well.