Structuring unit tests

[Matthias Lang]

Gaspar Chilingarov writes:

 > Well, and how do you test functions, which are not exported from foo module?
 > 
 > I'm getting a lot of utilitary functions,. which are used only inside of
 > module, but i want to test them explictly.
 > 
 > another question - how do you following thing in Erlang?
 > in OO world....

In the OO world, let's say C++, how do you test private member functions?

I can think of three straightforward ways and two insane ones

   1. You test those functions indirectly, i.e. by calling non-private
      member functions which you know exercise the private ones. You
      might use a test coverage tool to verify the "know" part.

   2. You incorporate (public) test functions in the class you're
      testing. Those test functions exercise the private functions.
      This is a special case of #1.

   3. You make a friend class and stick all the test code there.

  (4. You put '#define private public' in every translation unit,
      perhaps by means of a compiler directive in a Makefile)

  (5. You mess around with compiling to shared libraries, fiddle with
      name mangling and then find a way to use your knowledge of ELF
      to call the private members, assuming they're emitted.)

You can do all except for #3 in Erlang too. 

I generally stick to #1, occasionally resorting to #2.

In Erlang, #4 is accomplished by using the 'export_all' compiler
directive. Some frequent contributors to the mailing list consider
this a good way to test, others say it is madness.

Matt