Mock example - no test files and working offline

[kaihendry]

Hi, I'm struggling to understand the mocking example upon https://github.com/aws/aws-sdk-go-v2/tree/master/example/service/sqs/mockingClientsForTests

https://s.natalian.org/2018-02-06/mocking.mp4

Version of AWS SDK for Go?

39ee151

Version of Go (go version)?

go version go1.9.3 linux/amd64

What issue did you see?

?       command-line-arguments  [no test files]

Steps to reproduce

go test -tags example ifaceExample.go

from the README.md

Furthermore I tried to create a mocked example myself, but it still seems to dial out (it doesn't work whilst offline).

caused by: Get https://s3-ap-southeast-1.amazonaws.com/: dial tcp: lookup s3-ap-southeast-1.amazonaws.com: no such host

Is it because of the cfg?

• main.go http://play.golang.org/p/GE13V9V2wUx
• main_test.go http://play.golang.org/p/G4XhuTL33Ic

Perhaps you can suggest how to handle the config here so all the functions can access it without any hoop jumping?

[xibz]

Hello @kaihendry, thank you for reaching out to us. You are using the s3.S3 client when calling lsBuckets. Which is why it is hitting the endpoint. You would just use the mockS3Client you created directly instead of the s3.S3 client. Think of the mock client as a substitute client for testing.

[kaihendry]

Ok, so the existing structure I had where I was using a global cannot work here, right?

var (
       cfg, _ = external.LoadDefaultAWSConfig()
       client = s3.New(cfg)
)

Since IIUC, there is no way to override.

I think I got it working. https://s.natalian.org/2018-02-07/mocked.diff

Nonetheless what what the issue ? command-line-arguments [no test files] about with your test?

[gugahoi]

You probably don't need to create your own type, can just accept the interface as a parameter in the method (untested):

// main.go
package main

import (
	"fmt"

	"github.com/aws/aws-sdk-go-v2/service/s3"
	"github.com/aws/aws-sdk-go-v2/service/s3iface"
)

func lsBuckets(client s3.s3iface) (results *s3.ListBucketsOutput, err error) {
	req := client.ListBucketsRequest(&s3.ListBucketsInput{})
	return req.Send()
}

func main() {
	cfg, _ = external.LoadDefaultAWSConfig()
	client = s3.New(cfg)

	res, err := lsBuckets(client)
	if err == nil {
		fmt.Println(res)
	}
}

// main_test.go
package main

import (
	"testing"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/service/s3"
	"github.com/aws/aws-sdk-go-v2/service/s3/s3iface"
)

type mockS3Client struct {
	s3iface.S3API
}

func (m mockS3Client) ListBucketsRequest(input *s3.ListBucketsInput) *s3.ListBucketsRequest {
	return &s3.ListBucketsRequest{
		Request: &aws.Request{},
		Input:   &s3.ListBucketsInput{},
	}
}

func TestListBuckets(t *testing.T) {
	mockClient = mockS3Client{}

	_, err := lsBuckets(mockClient)
	if err != nil {
		t.Fatal(err)
	}
}

[kaihendry]

@gugahoi thanks for the alternative suggestion, though I don't like client as a parameter as it feels like some setup cruft I don't want to see an input to my function. Sorry, I'm probably being rather silly.

[xibz]

@kaihendry, you could also specify the type in the client declaration.

package main

import "fmt"

type Fooer interface{
    Foo() string
}

type Bar struct{}
func (b *Bar) Foo() string {
    return "baz"
}

var client Fooer = &Bar{}

func main() {
	fmt.Println(client.Foo())
}

[kaihendry]

Still don't quite understand how you would override client in main_test.go. Hopefully you'll add a simple example using an AWS API on https://github.com/aws/aws-sdk-go-v2/tree/master/example/service/sqs/mockingClientsForTests

[daviskoh]

hmmm from that it seems like ListBucketsRequest would return nil and Send() in lsBuckets would fails w/ something like:

panic: interface conversion: interface {} is nil

[gugahoi]

The point I wanted to make with that example is how you can mock a method in the struct and use the interface provided in the sdk. They have decent documentation on the interfaces themselves

// The best way to use this interface is so the SDK's service client's calls
// can be stubbed out for unit testing your code with the SDK without needing
// to inject custom request handlers into the SDK's request pipeline.
//
//    // myFunc uses an SDK service client to make a request to
//    // Amazon Simple Storage Service.
//    func myFunc(svc s3iface.S3API) bool {
//        // Make svc.AbortMultipartUpload request
//    }
//
//    func main() {
//        cfg, err := external.LoadDefaultAWSConfig()
//        if err != nil {
//            panic("failed to load config, " + err.Error())
//        }
//
//        svc := s3.New(cfg)
//
//        myFunc(svc)
//    }
//
// In your _test.go file:
//
//    // Define a mock struct to be used in your unit tests of myFunc.
//    type mockS3Client struct {
//        s3iface.S3API
//    }
//    func (m *mockS3Client) AbortMultipartUpload(input *s3.AbortMultipartUploadInput) (*s3.AbortMultipartUploadOutput, error) {
//        // mock response/functionality
//    }
//
//    func TestMyFunc(t *testing.T) {
//        // Setup Test
//        mockSvc := &mockS3Client{}
//
//        myfunc(mockSvc)
//
//        // Verify myFunc's functionality
//    }

[Skarlso]

The problem is that the Send is on the Request object. You can't mock that. Basically if you have something after send and you need a return object on that one, you don't have anything at your disposal to do that. You will just return an empty request and you won't be able to mock / stub out the Send function which actually returns a response that you can test further.

Basically you can just test up until Send. After that you will need to get clever. Maybe stash it away in your own function that you would mock out. Have an object that can encapsulate this send.

[Skarlso]

@kaihendry Please see my answer here that describes in detail with example on how to stub the Request in order to manipulate Send: #70 (comment)

[jasdel]

Hi all, along with the discussion on how best the SDK can facilitate mocking of API operations, I'd like to also link PR #265 which adds Context to the API operation request's Send method. This change is being made so the SDK presents the Context as a first class concept. This pattern also improves the SDK's integration with other tracing libraries, (e.g X-Ray, or httptrace)

[jasdel]

Sorry closed this issue by mistake.