There are many good arguments for hiding away the lower layers in your stack – essentially the building blocks upon which your public API is built - however the ‘we don’t have the time and resources to test that layer completely’ argument seems a little flawed to me.

Surely if you are sitting above a layer you have to test it thoroughly anyway?

And if the lower layer is all locked away, private or internal, that is going to be a LOT harder.

Imagine somebody trying to paint the bottom of a can through an open stay tab.


Not exactly the easiest thing in the world. But that is exactly what testing a private lower level API is like.

It would be much easier if you had complete and unfettered access to the inside of the can / lower level.

So if you have to test that surface anyway why not just make it public?

Counter Arguments?

Well, like all programming decisions, it’s not quite that simple. There are many nuances.

What for example if exposing your lower level API…

  1. Just isn’t that useful to your target audience?
  2. Requires too much orchestration and non-obvious call orders?
  3. Exposes you to more legal obligations?
  4. Would require a lot of supporting work like documentation etc?
  5. Might be wrong, and you don’t want to be locked into the current design forever?
  6. Means your software is no longer opinionated?

I’m sure you can think of many similar pivots.

That there are good reasons to keep things internal is beyond debate, what I hope everyone realizes though is that test cost alone probably isn’t reason enough.