Mock Client

[estahn]

As described in #148, a Client interface containing all available methods would be quite useful to add mocking abilities. In the current state, the HTTP client would need to be mocked, which would effectively test the PagerDuty library itself unnecessarily.

Here is an example from the AWS SDK: https://docs.aws.amazon.com/sdk-for-go/api/service/ecr/ecriface/

Example:

type mockPagerDutyClient struct {
	mock.Mock
	pagerduty.ClientAPI
}

func (m *mockPagerDutyClient) ListAbilities() (*ListAbilityResponse, error) {
	return &pagerduty.ListAbilityResponse{}, nil
}

...

pagerDutyClient := new(mockPagerDutyClient)
pagerDutyClient.On("ListAbilities", &pagerduty.ListAbilityResponse{}).Return(mock.Anything)

I could provide a PR. Thoughts?

[theckman]

Thank you for reaching out.

In Go, it's considered more idiomatic for consumers of a package to define their own local interface that describes what functionality they use. You then write your own minimal mock that implements only those methods, and provides the controls you need to mock responses and errors.

If you take a look at the v2 Go AWS SDK, they stopped offering these features as part of the rewrite because of these idioms. I'm in strong alignment with this decision, because doing this is additional API surface area we'd need to support.

So my initial thought is that we would not want to pursue adding this to this project.

[estahn]

@theckman Thanks for your thorough response.

There is certainly an advantage to define your own interface as it would lower breaking changes from upstream. On the contrary I would argue it’s repetitive and produced more unnecessary boilerplate.

Using the ECR API Interface was a pleasant experience and I’m surprised it was removed.

Do you possibly have some more reading on idiomatic go that supports this? Idiomatic code seems to be the knockout argument for any discussion.

[theckman]

@estahn Avoiding boilerplate definitely isn't something that the Go language really concerns itself with. In some ways, it actually encourages it based on two different Go Proverbs:

• A little copying is better than a little dependency.
• Clear is better than clever.

For this specific topic on where interfaces are defined, the canonical place I've seen it mentioned is in the CodeReviewComments wiki page on the official Go repo on GitHub: https://github.com/golang/go/wiki/CodeReviewComments#interfaces