News for hackers. Stuff that matters.
Re:When you shouldn't bother unit testing by tel on Friday May 17, 2013 @01:13PM (#5725544)
This "layered" effect of interface hiding is natural in pure functional contexts. In Haskell you often see exposed "Internal" modules for just this reason---they're not the primary API, but they're valuable to have around.

It's harder to have these layered effects in other languages (in my experience) though often distinctions between a concrete and abstract (interface driven) API are a good first layer.

Re:When you shouldn't bother unit testing by Chris_Newton on Friday May 17, 2013 @01:50PM (#5725782)
There is a lot of merit in allowing modules to offer multiple interfaces that clients can use as long as they explicitly request them. You can solve the multiple-levels-of-abstraction API problem that way, and you can solve production/test/debug access control problems that way too.

Unfortunately, most languages today have at best limited support for this idea. For example, plenty of languages with OOP tools offer both some sort of public/private distinction for access control and a concept of implementing one or more explicit interfaces, but these are usually treated as orthogonal features.

As long as you’re working in that kind of framework, or with more dynamic tools where you don’t necessarily have any concept of explicit interfaces at all, it’s going to be difficult to write unit tests without circumventing the normal access control and modularity mechanisms somehow.