How to unit test a component that uses third party library in golang?

I am new to golang and came from a java background.

Here is my problem today: How to unit test a component that uses a third-party library that doesn't provide an interface in Golang? Here is my concrete example:

I have a class that uses golang mongodb driver to implement some DB operations like below:

package mypackage


type myClientBeingTested struct {
	client *mongo.Client
}

func (mc *myClientBeingTested) FindOne(filter interface{}) (*mongo.SingleResult, error) {
    result := mc.client.FindOne(context.Background(), filter)
    if result.Err() == mongo.ErrNoDocuments {
        return nil, nil
    } else {
        return nil, Errors.New("My own error message")
    }
    return result, nil
}

Now I'd like to write some unit tests for this method and realized that it's impossible to mock a third party dependency that doesn't have an interface implementation. In the example above, mongo.Client is a struct type. After some researching and thinking, the only possible way seems to be like below:

package mypackage

type myClientBeingTested struct {
	client *mongo.Client
}

var findOneFunc = func(client *mongo.Client, ctx context.Context, filter interface{}) (*mongo.SingleResult, error) {
    return client.findOne(ctx, filter)
}

func (mc *myClientBeingTested) FindOne(filter interface{}) (*mongo.SingleResult, error) {
    result := findOneFunc(mc.client, filter)
    if result.Err() == mongo.ErrNoDocuments {
        return nil, nil
    } else {
        return nil, Errors.New("My own error message")
    }
    return result, nil
}

Then in my unit test I can stub findOneFunc with my own stub like below

findOneFunc = func(client *mongo.Client, ctx context.Context, filter interface{}) (*mongo.SingleResult, error) {
// my own implementation
}

But this seems to be a hack. Is there any authentic/recommended way to handling situations like that? Appreciate your responses!

It should be possible to write your own interface for the methods that you need to use from a struct imported from a 3rd party library.

type MongoClient interface {
  FindOne(context.Context, mongo.D) (*mongo.SingleResult, error)
}

type myClientBeingTested struct {
  client MongoClient
}

// in tests


type mockMongoClient struct {
  // implement MongoClient, pass in to myClientBeingTested
}

However for most apps it provides a better guarantee to run tests against a local or in memory database to verify that everything works end to end. If that becomes too slow it can make sense to mock at the business logic level instead of the database query level.

For example:

type User struct {}

type UserMgmt interface {
  Login(email, pass string) (*User, error)
}

// for testing api or workflows
type MockUserMgmt struct {}

// for production app
type LiveUserMgmt struct {
  client *mongo.Client
}

In the unit test it would look like:

// user_mgmt_test.go test code

userMgmt := &LiveUserMgmt{client: mongo.Connect("localhost")}
// test public library methods

In api or workflow tests it would look like:

userMgmt := &MockUserMgmt{}

// example pass to api routes
api := &RequestHandler{
  UserMgmt: userMgmt,
}

EDIT:
I'm too new to comment on my post, but re your question about mocking the struct, you apply the same principle. If the mongo type is a struct, you can create an interface (even with the same name) and depend on the interface instead of directly depending on the struct. Then via the interface you can mock out the methods you need to.

// The mongo struct you depend on and need to mock
type mongo struct {
  someState string
}

// The real world function you need to mock out
func (m *mongo) Foo() error {
  // do stuff
  return nil
}

// Construct an interface with a method that matches the signature you need to mock
type mockableMongoInterface interface {
  Foo() error
}

Now depend on mockableMongoInterface instead of directly on mongo. You can still pass your third party mongo struct to sites where you need it, because go will understand the type via the interface.

This aligns with Adrian's comment on your question.