The problem with providing an interface to all methods in a service is that you then need to provide implementations of all the methods in the interface when you mock it, which gets very old very fast. Whereas if you write your own interface, you can mock only the individual methods that you are actually using.

Do you have a specific problem in writing your unit tests, or were you just wanting to point out the philosophical differences between this repo and K8S ?

By the way, it is simple enough to write a Go script that would pump out an interface for every method in this repo, but again I think this is a genuinely bad idea.

Hi @gmlewis , you might not be fully aware that you can embed interfaces into structs in a way to automatically adhere to them. This allows you to just implement the methods you are actually calling for each scenario.

I totally agree with @artheus-sbab . Just like many other important libs for services like GCP, AWS, K8s provide interfaces for all of their services, this one should provide one too.

Here an example of what I'm saying:

package main

type Iface interface {
	Foo() string
	Bar() string
}

type FakeIFace struct {
	Iface // this allows FakeIface to automatically adhere to the interface

	// the caveat here is that if we actually call Foo() or Bar() this will cause a panic
	// but in unittests where we know which calls are being made, this is a non-issue
	// as we strategically implement only the required methods for that scenario
}

func (f *FakeIFace) Bar() string {
	return "Fake Bar()"
}

func TestIFace(f Iface) string {
	// in this specific usage of the interface
	// we know we only call one of the methods
	// and since we've embeded the interface
	// we can only override one of them
	return f.Bar()
}

func main() {
	// lets pretent this is a unittest

	fakeIFace := FakeIFace{}

	TestIFace(&fakeIFace)

}

Or if you prefer, https://play.golang.org/p/fU94md71VlS

Add Client interface/mock to allow Mocked testing #1800

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions