Calling internal functions - foo::bar() ?

Brian Buchanan brian@REDACTED
Tue Mar 1 00:15:29 CET 2005

>   Today many people use export_all so that they have a convenient way
>   to test internal functions in the shell.
>   This has the unfortunate side-effect of letting real modules call
>   not-explicitly-exported functions, and that in turn means that
>   export-lists can go stale because you don't notice when they're
>   wrong.
>   To remove 'export_all' is dangerous and it requires you to retest
>   your program. (What if you were "accidentally" calling unexported
>   functions while testing before?). This sucks because typically the
>   time you want to remove export_all is when you've just finished
>   testing and you notice it in 'cvs diff' before checkin -- i.e.
>   exactly when you don't want to make any changes.
>   If you do make the effort to correct your export lists and remove
>   your export_all's at some point then later you'll be tempted to put
>   them back in while hacking and debugging new versions of your
>   libraries.

The way that I deal with this is to put the test cases for a module at the
bottom of the source file for that module, wrapped in -ifdef(tests).  My
test harness, called from "make test", compiles each module using
cover:compile(module, [{d, tests}]), executes the test cases, prints
the results of the test, and warns of any uncovered functions.

This doesn't address the desire to test internal functions from the shell,
of course, but it solves my testability problem.

Testing from the shell could be addressed by manually compiling the module
and specifying export_all as an option to the compiler -- NOT putting it
in the source file.  This precludes accidentally checking in source code
that includes "-compile(export_all)", because it's never there in the
first place.  You could also easily add a make target or variable that
causes all your modules to be built +debug_info +export_all for
writing/debugging/testing, and builds them without those options for
production builds.

- Brian

Brian Buchanan <brian@REDACTED>
Principal Engineer
nCircle Network Security                   

More information about the erlang-questions mailing list