In Go, what do you trade away when a test fake embeds the interface it is meant to satisfy?

## The trick ```go type fakeStore struct { UserStore // embedded interface, left nil user User } func (f fakeStore) UserByID(ctx context.Context, id int64) (User, error) { return f.user, nil } ``` Embedding an interface in a struct promotes that interface's methods onto the struct's method set. The struct therefore satisfies the interface immediately, with zero methods written. Any method you *do* declare on the struct shadows the promoted one, so you implement only what the test exercises. ## What is actually stored The embedded field is an ordinary field named after the interface type, holding an interface value. Left out of the struct literal, it holds nil. The promoted methods are dispatched through that field, so calling one is a method call on a nil interface value: the program panics at runtime with `invalid memory address or nil pointer dereference`. That is the whole tradeoff in one sentence: satisfaction is guaranteed at compile time and correctness is deferred to runtime. ## The diagnostic you give up With an explicit fake, adding a method to the interface produces a build failure at the point where the fake is passed: the type no longer implements the interface, and the compiler lists the missing method. That error is a to-do list — it enumerates exactly which test files need attention before the change can land. It is one of the more useful compile errors in Go, and it is the reason a hand-written fake is a maintenance asset rather than a chore. Embed the interface and that error disappears. The new method is promoted, every fake still builds, and the suite still passes — until some case reaches code calling the new method, which panics. If the new call sits behind a condition few tests hit, the failure may not appear until much later, and the panic's stack trace points into the runtime, not at the fake's declaration. ## When embedding is nevertheless right Three situations justify it. First, an interface you do not control that is genuinely wide — writing and maintaining twenty stub methods is worse than the risk. Second, a fake used by many test files where only a couple of methods matter and the rest would be pure noise. Third, deliberately *seeking* the panic: some teams embed precisely so that any unanticipated call blows up loudly rather than returning zero values silently, which is a defensible bargain when the alternative is a fake that succeeds at everything. A middle path keeps both properties: embed a small base struct rather than the interface, where the base implements every method by failing the test. ```go type failingStore struct{ t *testing.T } func (f failingStore) UserByID(ctx context.Context, id int64) (User, error) { f.t.Fatalf("unexpected call to UserByID") return User{}, nil } type fakeStore struct { failingStore user User } ``` Now an unanticipated call fails the test with a readable message instead of panicking, and adding a method to the interface still breaks the *base* struct at compile time, which is exactly the one place you want to be told. ## The signal to read If embedding an interface into fakes has become the house style, that is usually evidence that the interfaces are too wide — describing an implementation rather than a consumer's need. Narrowing them to the one or two methods each caller actually uses removes the motive for the trick, and restores the compile error as your change-impact report. ## Two details worth knowing The promoted methods keep the embedded field's dynamic behaviour: if you *do* assign a real implementation into the embedded field, the fake delegates to it for everything you have not overridden. That makes the pattern a serviceable decorator — wrap a real collaborator and override one method — which is a legitimate use quite apart from testing. And a struct embedding an interface is not the same as a struct embedding a struct: with an interface, satisfaction is guaranteed but the implementation may be absent; with a struct, the methods are real code that always runs.