Magnus Therning schrieb:

On Wed, Feb 24, 2010 at 10:41, Arnaud Bailly wrote:

...

Maybe you just want to test what's in your export list which represents the public interface of your code. And if you cannot write a test that exercise private implementation through the public interface, then maybe there is a design problem...

Possibly!

The specific case I have is a module for parsing a small language. The module exports a single function, a function that takes a string and returns a tree. Of course the parser is built using parser combinators. I'd like to test each combinator I've built, but I don't want to export them all. The only way I see of achieving this is to split each module in two, one public and one internal, where the public one just re-exports the relevant pieces of the internal one. That's workable, but hardly aesthetically pleasing ;-)

It can be tedious to manage two variants of each module, but I often had to go this way anyway in order to avoid cyclic dependencies or because some modules need internals of other modules of the same package.