This is similar in nature to two things we do already:

1) the concurrency suite
2) passthrough suites, including the stepdown and last-stable suites

However, 1) doesn't give control over what is being run concurrently with the ops, and 2) is a heavyweight approach that requires blacklisting existing tests that don't work with the passthrough and considering whether each new test should be blacklisted.

I'd instead like a simple js lib containing something like:

var testCRUD = function(coll) { ... }
var testAgg = function(coll) { ... }
var testCount = function(coll) { ... }
var testDistinct = function(coll) { ... }
var testGroup = function(coll) { ... }
var testFindAndModify = function(coll) { ... }
var testMapReduce = function(db) { ... }

which can be load()'ed in a particular jstest. The jstest can then configure the cluster in any way desired (take down some nodes, slow down replication, drop messages, exercise the balancer, delete administrative sharding docs (e.g. shardIdentity, cluster version)) or the collection in any way desired (sharded or unsharded, with or without particular indexes) before running any subset (or all) of the functions in the lib.

This would be useful because we re-write these kinds of functions often in many jstests, which is time-consuming and more likely to have bugs.

A nice example the library could be based on is https://github.com/mongodb/mongo/blob/r3.3.12/jstests/sharding/collation_targeting.js, which tess.avitabile wrote for 3.4.