...

• Write a mock to to monkey patch the hack I put in - 1d
• Submit PRs to mongomock or fork and make changes - 1-2d
• Identify tests that should be mocked and add mocking to them - 2d (there are hundreds) 
• Investigate and fix up the dozen or so tests that were still failing (optional, could just not mock those tests) - 1d

...

New modulestore backend

Work

• Create a new (in local memory?) modulestore backend that can behave like old mongo and split mongo as necessary (~15 days?)
  
  • ~40 public methods in old mongo backend, ~60 in split
  • May take additional time / iterations to realize the full savings
• Identify tests that should be mocked and add mocking to them - 3d (there are hundreds) 

Savings

• Potential savings of 10 min plus on a full paver test run
  • Depending on how much savings we can squeeze from skipping various transformations, and whether we can fit everything we need to in local memory

Advantages

• Saves the most test time
• Clear boundaries

...

• Huge undertaking due to wide API and potential for some direct calls in to internals that may need to be mocked out or changed
• Likely to grow in scope as new access patterns / edge cases are discovered
• Needs to be maintained along with other storage engines
• Less authentic tests, may need to beef up integration tests for explicit backend old / split mongo testing

K/V level mock (2, 3)

...

• Still uses a lot of modulestore code, tests more authentic
• Probably saves about the same amount of time as mocking Mongo
• Much smaller API footprint to mock out1Can be used selectively (and explicitly) in a decorator or context managerout
• No new deps

Disadvantages

• Leaves a lot of modulestore test time
• Probably still a fair amount of work
• Depending on usage may need an outside memory store (or just use memcached if it's there?)
• May need different implementations for different modulestore backends to get full benefits, potentially tripling the work

...