For a paper I am writing, I need to find the origin of the following two phrases:

Code against the interface, not the implementation


Test the interface, not the implementation

(Note: the second is more important to me than the first.)

I googled around, but was unable to find anything. Apparently, everyone knows these two mantras, and many keep repeating them, but nobody seems to cite a source.

Surely, someone must have said them first, no?

  • It could be that the phrase "Program to an interface, not an implementation." first appeared in that specific form in Go4 Design Patterns as the answer bellow points out, but I think that the idea itself predates that book, so you'd have to do some reference tracking / digging, perhaps even to early computer science papers. The second idea is essentially the application of the first one to testing, and is associated with black-box testing, as well as with TDD (Kent Beck–style), as to avoid brittle tests and enable refactoring, so look in that direction. Commented Sep 22, 2021 at 18:22
  • Does this answer your question? What is the origin of "Program to an interface, not an implementation"? Commented Sep 22, 2021 at 20:51
  • @Deduplicator thanks, this Q&A did not show up when I was entering my question. Unfortunately, the one and only answer to it does not seem to be particularly on-topic.
    – Mike Nakis
    Commented Sep 24, 2021 at 6:49
  • 1
    @Deduplicator actually, it turns out that I was --in theory-- aware of that Q&A, since I commented on it back in 2016. (-:=
    – Mike Nakis
    Commented Sep 24, 2021 at 6:58
  • Although often propagated as a means to enable testing, the first statement is a more general recommendation to minimize dependencies. It is the D in SOLID, the dependency inversion principle: depend on abstractions, not concretions. I do not think the question who said it first is particularly meaningful regarding the general nature of the advise in a logical modeling context. Since we have scissors people have been advised to not run with them for obvious reasons. Does it matter who spoke the words first? Commented Oct 2, 2021 at 8:26

1 Answer 1


The most often-cited source of Program to an interface, not an implementation. is GoF Design Patterns (1995): https://en.wikipedia.org/wiki/Design_Patterns#Introduction

Chapter 1 is a discussion of object-oriented design techniques, based on the authors' experience, which they believe would lead to good object-oriented software design, including:

  • "Program to an interface, not an implementation." (Gang of Four 1995:18)
  • Composition over inheritance: "Favor 'object composition' over 'class inheritance'." (Gang of Four 1995:20)

(also: https://www.artima.com/articles/design-principles-from-design-patterns )

I've never heard of any principle recommending "Test the interface, not the implementation".

Unless I'm completely misunderstanding the intention behind this advice, I see no reason for such a principle to exist because it seems to be an unnecessary antagonisation of white-box and black-box testing.

Unlike other GoF principles, there is generally no reason why one type of testing should necessarily exclude the other, and indeed you would ideally have both if time/deadlines allow for it.

Furthermore, each type of testing has its own separate advantages and disadvantages. In many cases using both together, despite some likely testing overlap, can be complementary by providing insight and protection from different perspectives.

  • 2
    „Test the interface, not the implementation” may come from TDD: in TDD you don’t have the implementation when you write your tests, but only the interface (aka specification). As a side note: in testing safety critical applications it is required to achieve complete coverage of the implementation based on the requirements (aka specification) alone. In my experience this is a good principle: difficult to achieve but very rewarding. It makes you think hard about your interface and it’s specification (aka documentation), usually with very good results. Commented Sep 23, 2021 at 8:02
  • oh wow, the question was reopened. Let's see if anyone else has anything to day. Otherwise, I will accept this answer after a couple of more days.
    – Mike Nakis
    Commented Oct 1, 2021 at 17:38
  • I tend to second that quote, though. Testing against the implementation (details) leads to more brittle test implementations. And that counteracts the value of the test to guard against regressions (the test somehow becomes the regression). If you have to change the test when you refactor some unit, I think that's a smell. The API of some implementation should therefore always be the most stable thing, and the test should be against the API, not implementation (details).
    – nepa
    Commented Jan 8 at 8:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.