A Go test's hand-written fake must implement six methods though the code calls two. What went wrong?

## What the six-method fake is telling you Effort in a test double is a measurement. When a stand-in has to implement four methods the code under test never calls, the interface is describing the *implementation*, not the *dependency*. Someone enumerated everything the database layer can do and called that an abstraction. In Go the fix is unusually cheap, because interfaces are satisfied structurally and any package may declare one. ## Width is paid by implementers ```go // Too wide: declared to mirror the store type Repository interface { UserByID(ctx context.Context, id int64) (User, error) SaveUser(ctx context.Context, u User) error DeleteUser(ctx context.Context, id int64) error ListUsers(ctx context.Context) ([]User, error) Count(ctx context.Context) (int, error) Ping(ctx context.Context) error } ``` Every type that wants to stand in for this must supply six methods. There is exactly one real implementation and N test implementations, so the cost lands almost entirely on tests. Worse, each of those four unused methods is dead weight that a reader must check before concluding what the service touches. Narrow it to the need: ```go type userReader interface { UserByID(ctx context.Context, id int64) (User, error) } ``` The real store already has that method, so it satisfies the new interface with no edit. Nothing about the production wiring changes; only the declared dependency shrinks. ## Three costs a wide interface carries beyond typing **It leaks the producer's types.** A method like `Begin(ctx context.Context) (*sql.Tx, error)` in the interface forces the consuming package to import `database/sql` in order to name the type — so the abstraction that was supposed to decouple the packages has hard-wired one to the other. A narrow interface usually mentions only the consumer's own domain types. **It hides intent.** `Repository` says "anything a database can do". `userReader` says "this code reads one user by id". The second is documentation that the compiler enforces, and it tells a reviewer where to look for effects. **It multiplies churn.** Add a seventh method to the shared interface for one new caller, and every hand-written fake in every package stops compiling until somebody adds a stub. That is a real, recurring tax, and it is why teams that share one god interface end up embedding it into their fakes just to stop the breakage — trading a compile error for a runtime nil panic later. ## But isn't duplicating the signature bad? This is the objection worth answering directly, because engineers arriving from languages where interfaces are declared once and implemented explicitly find consumer-side declaration wasteful. In Go, repeating a method signature in two consuming packages duplicates a line of *description*, not behaviour. The two interfaces are then free to diverge: one consumer can keep a single-method view forever while another grows a second method, and neither forces a change on the other or on the implementation. The rule of thumb: an interface with more methods than the calling code uses is a design smell, and one method is the common case. Two is fine when the same operation genuinely needs both — say a read and a write inside one transaction-shaped workflow. Beyond that, ask whether you are looking at one dependency or several, and whether the consumer should take two parameters instead of one. ## Naming and export A consumer-side interface used only inside the package is usually unexported (`userReader`), which is a signal that it is a local description and not part of anybody's API. Export it only if callers outside the package must name it — for example, because it appears in an exported constructor's signature. ## A test that gets easier as a result With one method, the fake is four lines and every case is a struct literal: ```go type fakeReader struct { user User err error } func (f fakeReader) UserByID(ctx context.Context, id int64) (User, error) { return f.user, f.err } ``` The review signal is simple: if writing the stand-in feels like clerical work, the interface is describing the wrong thing. Shrink the interface first, and the test double shrinks with it.