Previously, we have addressed requests to improve testability of applications that use the Go Driver in an ad-hoc manner. We should try to define a complete set of testing use cases and come up with a story for how we intend to support (or why we won't support) each one of them.

Original description:

Requests to convert our main API types (Collection, Database, Client, etc.) to interfaces instead of basic structs are continuing to come in. It's clear that users desire a more seamless way of mocking the behavior of the Go driver for their own testing. See related tickets and online discussions (GODRIVER-2161, GODRIVER-1241, GODRIVER-834, community forum posts, and comments on our PRs).

For reasons of backwards-compatibility (usually, any additions to Go interfaces require major releases under SemVer) and Go best practices (Go official documentation advises against returning interfaces in the "implementer API"), we are against converting the structs to interfaces. But, we should really investigate alternative solutions here and think about ways to ease this user burden.