Context

The standard pattern for using mtest is to initialize the wrapper instance at the beginning of a test and then use mt.Run or mt.RunOpts instead of t.Run to run subtests and use mt as the target for test assertions. That creates some issues:

1. Sharing resources between subtests can create unexpected behaviors. Options like CreateClient and ShareClient are intended to help, but are confusing and it's not obvious what's going on with the clients under the cover.
2. It's easy to accidentally use t instead of mt for assertions, resulting in test failures that don't indicate which subtest failed.
3. IDE integrations don't recognize RunOpts as a subtest function, so don't offer "Run test" shortcuts.

Instead of wrapping the testing.T type, it would be better if mtest was a simple helper that provided access to the CI MongoDB deployments. For example:

func TestSomething(t *testing.T) {
    t.Run("...", func(t *testing.T) {
        mt := mtest.NewV2(t)

        _, err := mt.Coll().InsertOne(...)
        require.NoError(t, err)
        // ...
    })
}

Definition of done

• Create a new mtest type that offers similar behavior as the current mtest.T type, but doesn't provide any methods from the testing.T type. Don't try to copy/implement all methods from mtest.T, only the minimal set required to refactor the first test function.
• Deprecate mtest.T.Run and mtest.T.RunOpts.
• Refactor at least one prose test to use the new mtest API.

Pitfalls

• Refactoring tests to use the new API will be a lot of work.