Structuring unit tests
Mon Apr 18 08:57:23 CEST 2005
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.
More information about the erlang-questions