How to properly test a handler that calls another function inside of it - unit-testing

I am looking to test the PostUser function that looks something like this (error handling omitted for simplicity):
func PostUser(env *Env, w http.ResponseWriter, req *http.Request) error {
decoder := json.NewDecoder(req.Body)
decoder.Decode(&user)
if len(user.Username) < 2 || len(user.Username) > 30 {
return StatusError{400, errors.New("usernames need to be more than 2 characters and less than 30 characters")}
}
emailRe := regexp.MustCompile(`^[a-z0-9._%+\-]+#[a-z0-9.\-]+\.[a-z]{2,4}$`)
if !emailRe.MatchString(user.Email) {
return StatusError{400, errors.New("invalid email address")}
}
if len(user.Password) < 8 {
return StatusError{400, errors.New("passwords need to be more at least 8 characters")}
}
hashedPassword,_ := bcrypt.GenerateFromPassword([]byte(user.Password), 12)
env.DB.InsertUser(user.Username, hashedPassword, user.Email) // need to mock this out
userData,_ := json.Marshal(user)
defer req.Body.Close()
w.Write(userData)
return nil
}
My env.go file looks like this:
type Env struct {
DB *db.DB
}
My db.go file looks like this:
type DB struct {
Session *mgo.Session
}
How do I mock the InsertUser call by my DB struct, so that I can unit test the PostUser?

To use mocks for testing you need to create an interface that your mock can implement. Naturally, the struct you're replacing the mock with also needs to implement all the methods of the interface so that they are freely interchangeable.
For example, you could have an interface:
type DBInterface interface {
InsertUser(string, string, string)
//all other methods on the DB struct here
}
Then your DB struct already implements all the methods of the interface. From there you can create a mock struct that also implements the interface.
type DBMock struct {}
func (dbm *DBMock) InsertUser(username, password, email string) {
//whatever mock functionality you want here
return
}
//all other methods also implemented.
Then you can alter env to have a pointer to a DBInterface instead of a DB. When you setup the env to be passed into the handler, in the production version use the DB struct and in testing use the DBMock struct.

Related

Golang GORM DB mock

I have to mock test a service.to create new service i need to pass gorm.DB{} but every time i pass it and run the test i get nil pointer error(panic).
please help on how to mock gorm.DB{} instance correctly for unit testing.
func NewService(db *gorm.DB) Service {
return &service{
repo: newReactionRepo(db),
}
}
making the mock call in the test like this :-
mockDB = &gorm.DB{}
package.NewService(mockDB)
getting this error
testing.tRunner.func1.2({0x1648e40, 0x21cdd60})
C:/Program Files/Go/src/testing/testing.go:1396 +0x24e
testing.tRunner.func1()
C:/Program Files/Go/src/testing/testing.go:1399 +0x39f
panic({0x1648e40, 0x21cdd60})
C:/Program Files/Go/src/runtime/panic.go:884 +0x212
gorm.io/gorm.(*DB).Session(0x21ef260, 0xc000861a50)
C:/Users/acb/sdk/go1.17/pkg/mod/gorm.io/gorm#v1.24.2/gorm.go:215 +0x3b
gorm.io/gorm.(*DB).WithContext(...)
You could initialize db, ie:
//...
mockDB := initDb()
package.NewService(mockDB)
//...
func initDb() *gorm.DB {
dsn := "host=localhost user=myuser password=mypassword dbname=mydb port=5432 sslmode=disable"
db, err := gorm.Open(postgres.Open(dsn))
if err != nil {
log.Fatal("couldn't connect to db")
}
return db
}
Since the gorm.DB type is a struct, it makes unit testing with it directly a bit difficult. With the nil pointer error you are getting, you may need to modify your code to check for a nil value passed in so that it doesn't try and call methods on a nil pointer.
If you want to have unit tests, you could wrap your database operations in an interface, and then provide a mock implementation that does not use a real database. This can be done by creating an interface that defines the methods needed for interacting with the database, and then creating a struct that implements this interface for the actual database operations.
For example:
// Database is an interface that defines methods for interacting with a database.
type Database interface {
Create(data interface{}) error
GetByID(id int, result interface{}) error
}
// RealDatabase is a struct that implements the Database interface
// using a real GORM connection.
type RealDatabase struct {
// db is a connection to the database
db *gorm.DB
}
// Create saves the data in the database
func (rdb *RealDatabase) Create(data interface{}) error {
return rdb.db.Create(data).Error
}
// GetByID retrieves the data by ID from the database
func (rdb *RealDatabase) GetByID(id int, result interface{}) error {
return rdb.db.First(result, id).Error
}
// MockDatabase is a struct that implements the Database interface
// using a mock GORM connection.
type MockDatabase struct {
// data is a map of ID to data used for mocking.
data map[int]interface{}
}
// Create does not do anything but returns no errors
func (mdb *MockDatabase) Create(data interface{}) error {
return nil
}
// GetByID returns the data for a given ID
func (mdb *MockDatabase) GetByID(id int, result interface{}) error {
data, ok := mdb.data[id]
if !ok {
return fmt.Errorf("data not found for ID: %d", id)
}
result = data
return nil
}
In this example, the RealDatabase struct uses GORM to interact with the database, while the MockDatabase struct uses a map to mimic the behavior of the real database. The Create method in the MockDatabase struct does nothing and returns no errors, and the GetByID method returns the data for a given ID. You can also add more functionality to the mock struct and the interface to mimic the behavior of the real database as needed.
Finally, you could also use the Gomock library, which provides tools to automatically generate mock versions of interfaces you provide to it.
You might try something using composition.
type DBInstance struct {
*gorm.DB
}
Pass an instance of DBInstance to NewService(db DBInstance) instead of *gorm.DB. You can mock the methods of *gorm.DB that are used when unit testing your code. Example:
func (DBInstance) Find(dest interface{}, conds ...interface{}) (tx *DB) {
// mock implementation of gorm.DB.Find()
}
When calling from actual code use initialize DB instance using the db instance:
dsn := "host=localhost user=myuser password=mypassword dbname=mydb port=5432 sslmode=disable"
db, err := gorm.Open(postgres.Open(dsn))
dbInstance := DBInstance{
&db,
}
When calling from unit test, pass an empty uninitialized *gorm.DB object and mock all the required methods.
dbInstance := DBInstance{
&gorm.DB{},
}

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.

Golang Mocking - problems with type collision

I'm mocking out a DataStore and it's Get/Set functionality. The trouble I'm having is: cannot use s (type *MockStore) as type *datastore.Storage in argument to EventHandler
This is caused by my EventHandler function needing to be passed a *datastore.Storage as an argument type. I want to Test (http test) EvenHandler() using the MockStore I've created instead of the real datastore. I'm using the golang testify mock package.
Some Code Examples
type MockStore struct{
mock.Mock
}
func (s *MockStore) Get() ...
func EventHandler(w http.ResponseWriter, r *http.Request, bucket *datastore.Storage){
//Does HTTP stuff and stores things in a data store
// Need to mock out the data store get/sets
}
// Later in my Tests
ms := MockStore
EventHandler(w,r,ms)
A few things:
Create an interface that will be implemented both by datastore.Storage and your mock store.
Use the above interface as the argument type in EventHandler (not a pointer to the interface).
Pass a pointer to your MockStore to EventHandler, as the Get method is defined for a pointer to the struct.
Your updated code should be something like the following:
type Store interface {
Get() (interface{}, bool) // change as needed
Set(interface{}) bool
}
type MockStore struct {
mock.Mock
}
func (s *MockStore) Get() ...
func EventHandler(w http.ResponseWriter, r *http.Request,bucket datastore.Storage){
//Does HTTP stuff and stores things in a data store
// Need to mock out the data store get/sets
}
// Later in my Tests
ms := &MockStore{}
EventHandler(w,r,ms)

How to test call expectation in Go

I have a class MyClass that I want to test.
MyClass has a void method that calls an inner server to do something.
func (d *MyClass) SendToServer(args)
do stuff....
server.Send(myMessage)
I want to mock the server call Send, but since the method is a void method I can't be sure that I am actually calling it right.
These are the options I had in mind:
Use gomock, mock the server, and set expectations on the send method of the service
create my own MockServer, and "override" the method Send with a bunch of verifications. Something like:
func (d *MockedServer) Send(message)
// verify message...
create my own MockServer, but instead of verifying the expectation within the method, add the message to a list of messages, and then verify the content of the list.
What is a better approach in Go?
You could make a function out of your method like this:
var sendToServer = (*Server).Send
func func (d *MyClass) SendToServer(args) {
// ...
sendToServer(server, msg)
// ...
}
And in your tests:
func TestMyClass_SendToServer(t *testing.T) {
// ...
sent := false
sendToServer = func(*Server, args) {
sent = true
}
mc.SendToServer(args)
if !sent {
t.Error("fail")
}
}
This is described in Andrew Gerrand's Testing Techniques talk.

Mock functions in Go

I'm puzzled with dependencies. I want to be able to replace some function calls with mock ones. Here's a snippet of my code:
func get_page(url string) string {
get_dl_slot(url)
defer free_dl_slot(url)
resp, err := http.Get(url)
if err != nil { return "" }
defer resp.Body.Close()
contents, err := ioutil.ReadAll(resp.Body)
if err != nil { return "" }
return string(contents)
}
func downloader() {
dl_slots = make(chan bool, DL_SLOT_AMOUNT) // Init the download slot semaphore
content := get_page(BASE_URL)
links_regexp := regexp.MustCompile(LIST_LINK_REGEXP)
matches := links_regexp.FindAllStringSubmatch(content, -1)
for _, match := range matches{
go serie_dl(match[1], match[2])
}
}
I'd like to be able to test downloader() without actually getting a page through http - i.e. by mocking either get_page (easier since it returns just the page content as a string) or http.Get().
I found this thread which seems to be about a similar problem. Julian Phillips presents his library, Withmock as a solution, but I'm unable to get it to work. Here's the relevant parts of my testing code, which is largely cargo cult code to me, to be honest:
import (
"testing"
"net/http" // mock
"code.google.com/p/gomock"
)
...
func TestDownloader (t *testing.T) {
ctrl := gomock.NewController()
defer ctrl.Finish()
http.MOCK().SetController(ctrl)
http.EXPECT().Get(BASE_URL)
downloader()
// The rest to be written
}
The test output is following:
ERROR: Failed to install '_et/http': exit status 1 output: can't load
package: package _et/http: found packages http (chunked.go) and main
(main_mock.go) in
/var/folders/z9/ql_yn5h550s6shtb9c5sggj40000gn/T/withmock570825607/path/src/_et/http
Is the Withmock a solution to my testing problem? What should I do to get it to work?
Personally, I don't use gomock (or any mocking framework for that matter; mocking in Go is very easy without it). I would either pass a dependency to the downloader() function as a parameter, or I would make downloader() a method on a type, and the type can hold the get_page dependency:
Method 1: Pass get_page() as a parameter of downloader()
type PageGetter func(url string) string
func downloader(pageGetterFunc PageGetter) {
// ...
content := pageGetterFunc(BASE_URL)
// ...
}
Main:
func get_page(url string) string { /* ... */ }
func main() {
downloader(get_page)
}
Test:
func mock_get_page(url string) string {
// mock your 'get_page()' function here
}
func TestDownloader(t *testing.T) {
downloader(mock_get_page)
}
Method2: Make download() a method of a type Downloader:
If you don't want to pass the dependency as a parameter, you could also make get_page() a member of a type, and make download() a method of that type, which can then use get_page:
type PageGetter func(url string) string
type Downloader struct {
get_page PageGetter
}
func NewDownloader(pg PageGetter) *Downloader {
return &Downloader{get_page: pg}
}
func (d *Downloader) download() {
//...
content := d.get_page(BASE_URL)
//...
}
Main:
func get_page(url string) string { /* ... */ }
func main() {
d := NewDownloader(get_page)
d.download()
}
Test:
func mock_get_page(url string) string {
// mock your 'get_page()' function here
}
func TestDownloader() {
d := NewDownloader(mock_get_page)
d.download()
}
If you change your function definition to use a variable instead:
var get_page = func(url string) string {
...
}
You can override it in your tests:
func TestDownloader(t *testing.T) {
get_page = func(url string) string {
if url != "expected" {
t.Fatal("good message")
}
return "something"
}
downloader()
}
Careful though, your other tests might fail if they test the functionality of the function you override!
The Go authors use this pattern in the Go standard library to insert test hooks into code to make things easier to test:
https://golang.org/src/net/hook.go
https://golang.org/src/net/dial.go#L248
https://golang.org/src/net/dial_test.go#L701
I'm using a slightly different approach where public struct methods implement interfaces but their logic is limited to just wrapping private (unexported) functions which take those interfaces as parameters. This gives you the granularity you would need to mock virtually any dependency and yet have a clean API to use from outside your test suite.
To understand this it is imperative to understand that you have access to the unexported methods in your test case (i.e. from within your _test.go files) so you test those instead of testing the exported ones which have no logic inside beside wrapping.
To summarize: test the unexported functions instead of testing the exported ones!
Let's make an example. Say that we have a Slack API struct which has two methods:
the SendMessage method which sends an HTTP request to a Slack webhook
the SendDataSynchronously method which given a slice of strings iterates over them and calls SendMessage for every iteration
So in order to test SendDataSynchronously without making an HTTP request each time we would have to mock SendMessage, right?
package main
import (
"fmt"
)
// URI interface
type URI interface {
GetURL() string
}
// MessageSender interface
type MessageSender interface {
SendMessage(message string) error
}
// This one is the "object" that our users will call to use this package functionalities
type API struct {
baseURL string
endpoint string
}
// Here we make API implement implicitly the URI interface
func (api *API) GetURL() string {
return api.baseURL + api.endpoint
}
// Here we make API implement implicitly the MessageSender interface
// Again we're just WRAPPING the sendMessage function here, nothing fancy
func (api *API) SendMessage(message string) error {
return sendMessage(api, message)
}
// We want to test this method but it calls SendMessage which makes a real HTTP request!
// Again we're just WRAPPING the sendDataSynchronously function here, nothing fancy
func (api *API) SendDataSynchronously(data []string) error {
return sendDataSynchronously(api, data)
}
// this would make a real HTTP request
func sendMessage(uri URI, message string) error {
fmt.Println("This function won't get called because we will mock it")
return nil
}
// this is the function we want to test :)
func sendDataSynchronously(sender MessageSender, data []string) error {
for _, text := range data {
err := sender.SendMessage(text)
if err != nil {
return err
}
}
return nil
}
// TEST CASE BELOW
// Here's our mock which just contains some variables that will be filled for running assertions on them later on
type mockedSender struct {
err error
messages []string
}
// We make our mock implement the MessageSender interface so we can test sendDataSynchronously
func (sender *mockedSender) SendMessage(message string) error {
// let's store all received messages for later assertions
sender.messages = append(sender.messages, message)
return sender.err // return error for later assertions
}
func TestSendsAllMessagesSynchronously() {
mockedMessages := make([]string, 0)
sender := mockedSender{nil, mockedMessages}
messagesToSend := []string{"one", "two", "three"}
err := sendDataSynchronously(&sender, messagesToSend)
if err == nil {
fmt.Println("All good here we expect the error to be nil:", err)
}
expectedMessages := fmt.Sprintf("%v", messagesToSend)
actualMessages := fmt.Sprintf("%v", sender.messages)
if expectedMessages == actualMessages {
fmt.Println("Actual messages are as expected:", actualMessages)
}
}
func main() {
TestSendsAllMessagesSynchronously()
}
What I like about this approach is that by looking at the unexported methods you can clearly see what the dependencies are. At the same time the API that you export is a lot cleaner and with less parameters to pass along since the true dependency here is just the parent receiver which is implementing all those interfaces itself. Yet every function is potentially depending only on one part of it (one, maybe two interfaces) which makes refactors a lot easier. It's nice to see how your code is really coupled just by looking at the functions signatures, I think it makes a powerful tool against smelling code.
To make things easy I put everything into one file to allow you to run the code in the playground here but I suggest you also check out the full example on GitHub, here is the slack.go file and here the slack_test.go.
And here the whole thing.
I would do something like,
Main
var getPage = get_page
func get_page (...
func downloader() {
dl_slots = make(chan bool, DL_SLOT_AMOUNT) // Init the download slot semaphore
content := getPage(BASE_URL)
links_regexp := regexp.MustCompile(LIST_LINK_REGEXP)
matches := links_regexp.FindAllStringSubmatch(content, -1)
for _, match := range matches{
go serie_dl(match[1], match[2])
}
}
Test
func TestDownloader (t *testing.T) {
origGetPage := getPage
getPage = mock_get_page
defer func() {getPage = origGatePage}()
// The rest to be written
}
// define mock_get_page and rest of the codes
func mock_get_page (....
And I would avoid _ in golang. Better use camelCase
the simplest way is to set function into a global variable and before test set your custom method
// package base36
func GenerateRandomString(length int) string {
// your real code
}
// package teamManager
var RandomStringGenerator = base36.GenerateRandomString
func (m *TeamManagerService) CreateTeam(ctx context.Context) {
// we are using the global variable
code = RandomStringGenerator(5)
// your application logic
return nil
}
and in your test, you must first mock that global variable
teamManager.RandomStringGenerator = func(length int) string {
return "some string"
}
service := &teamManager.TeamManagerService{}
service.CreateTeam(context.Background())
// now when we call any method that user teamManager.RandomStringGenerator, it will call our mocked method
another way is to pass RandomStringGenerator as a dependency and store it inside TeamManagerService and use it like this:
// package teamManager
type TeamManagerService struct {
RandomStringGenerator func(length int) string
}
// in this way you don't need to change your main/where this code is used
func NewTeamManagerService() *TeamManagerService {
return &TeamManagerService{RandomStringGenerator: base36.GenerateRandomString}
}
func (m *TeamManagerService) CreateTeam(ctx context.Context) {
// we are using the struct field variable
code = m.RandomStringGenerator(5)
// your application logic
return nil
}
and in your test, you can use your own custom function
myGenerator = func(length int) string {
return "some string"
}
service := &teamManager.TeamManagerService{RandomStringGenerator: myGenerator}
service.CreateTeam(context.Background())
you are using testify like me :D you can do this
// this is the mock version of the base36 file
package base36_mock
import "github.com/stretchr/testify/mock"
var Mock = mock.Mock{}
func GenerateRandomString(length int) string {
args := Mock.Called(length)
return args.String(0)
}
and in your test, you can use your own custom function
base36_mock.Mock.On("GenerateRandomString", 5).Return("my expmle code for this test").Once()
service := &teamManager.TeamManagerService{RandomStringGenerator: base36_mock.GenerateRandomString}
service.CreateTeam(context.Background())
Warning: This might inflate executable file size a little bit and cost a little runtime performance. IMO, this would be better if golang has such feature like macro or function decorator.
If you want to mock functions without changing its API, the easiest way is to change the implementation a little bit:
func getPage(url string) string {
if GetPageMock != nil {
return GetPageMock()
}
// getPage real implementation goes here!
}
func downloader() {
if GetPageMock != nil {
return GetPageMock()
}
// getPage real implementation goes here!
}
var GetPageMock func(url string) string = nil
var DownloaderMock func() = nil
This way we can actually mock one function out of the others. For more convenient we can provide such mocking boilerplate:
// download.go
func getPage(url string) string {
if m.GetPageMock != nil {
return m.GetPageMock()
}
// getPage real implementation goes here!
}
func downloader() {
if m.GetPageMock != nil {
return m.GetPageMock()
}
// getPage real implementation goes here!
}
type MockHandler struct {
GetPage func(url string) string
Downloader func()
}
var m *MockHandler = new(MockHandler)
func Mock(handler *MockHandler) {
m = handler
}
In test file:
// download_test.go
func GetPageMock(url string) string {
// ...
}
func TestDownloader(t *testing.T) {
Mock(&MockHandler{
GetPage: GetPageMock,
})
// Test implementation goes here!
Mock(new(MockHandler)) // Reset mocked functions
}
I have been in similar spot. I was trying to write unitTest for a function which had numerous clients calling it. let me propose 2 options that I explored. one of which is already discussed in this thread, I will regardless repeat it for the sake of people searching.
Method 1: Declaring function you wanna mock as a Global variable
one option is declaring a global variable (has some pit falls).
eg:
package abc
var getFunction func(s string) (string, error) := http.Get
func get_page(url string) string {
....
resp, err := getFunction(url)
....
}
func downloader() {
.....
}
and the test func will be as follows:
package abc
func testFunction(t *testing.T) {
actualFunction := getFunction
getFunction := func(s string) (string, error) {
//mock implementation
}
defer getFunction = actualFunction
.....
//your test
......
}
NOTE: test and actual implementation are in the same package.
there are some restrictions with above method thought!
running parallel tests is not possible due to risk of race conditions.
by making function a variable, we are inducing a small risk of reference getting modified by future developers working in same package.
Method 2: Creating a wrapped function
another method is to pass along the methods you want to mock as arguments to the function to enable testability. In my case, I already had numerous clients calling this method and thus, I wanted to avoid violating the existing contracts. so, I ended up creating a wrapped function.
eg:
package abc
type getOperation func(s string) (string, error)
func get_page(url string, op getOperation) string {
....
resp, err := op(url)
....
}
//contains only 2 lines of code
func downloader(get httpGet) {
op := http.Get
content := wrappedDownloader(get, op)
}
//wraps all the logic that was initially in downloader()
func wrappedDownloader(get httpGet, op getOperation) {
....
content := get_page(BASE_URL, op)
....
}
now for testing the actual logic, you will test calls to wrappedDownloader instead of Downloader and you would pass it a mocked getOperation. this is allow you to test all the business logic while not violating your API contract with current clients of the method.
Considering unit test is the domain of this question, highly recommend you to use monkey. This Package make you to mock test without changing your original source code. Compare to other answer, it's more "non-intrusive".
main
type AA struct {
//...
}
func (a *AA) OriginalFunc() {
//...
}
mock test
var a *AA
func NewFunc(a *AA) {
//...
}
monkey.PatchMethod(reflect.TypeOf(a), "OriginalFunc", NewFunc)
Bad side is:
Reminded by Dave.C, This method is unsafe. So don't use it outside of unit test.
Is non-idiomatic Go.
Good side is:
Is non-intrusive. Make you do things without changing the main code. Like Thomas said.
Make you change behavior of package (maybe provided by third party) with least code.