[erlang-questions] I Hate Unit Testing...

[Tim Watson]

> Familiarity is utmost so I just borrowed/subverted the term structure
> used for .app files, like this...
> ----- my_app.test ------
> %% utest test specification
> {utest, my_app,
>  [{description, ""},
>   {version, "0.1"},
>   {flags, [verbose]}, %% only [verbose] or [] supported
>   {applications, [kernel, stdlib, crypto]}, %% dependencies
>   {tests, [
>        % Tests are specified as Module, Function, ArgumentList, ExpectedResult
>        % i.e. {M, F, A, R}
>    {my_module, hex, [2], "2"},
>    {my_module, hex, [255], "ff"},
>    {my_module, hex, [55551], "d8ff"}
>   ]}
> ]}.
>

I do like the declarative approach to defining tests. In Haskell, the
QuickCheck tool assumes a similar idea
(http://www.haskell.org/haskellwiki/QuickCheck_as_a_test_set_generator),
albeit less tied to specific inputs/outputs.

One thing I would like to make note of, is that this doesn't actually
test the parts of your code that are likely to go wrong. In a
language/platform that provides referential transparency, you can
certainly provide 'proofs' about the behavior of your *pure* functions
and have these automatically asserted/verified. The more problematic
area, and the one on in which you're more likely to run in to issues,
is that of impure functions (i.e. those with side effects). Hitting
the file system, network I/O, talking to other (erlang) nodes and most
importantly I would think - processes sending and receiving messages
and responding to them. In this area, all kinds of things can happen -
what order do messages come in vs. get processed, how are
servers/services contacted and 'looked up', is registration
synchronized correctly, do gen_servers get started up in the correct
order, etc. These latter points seem more likely candidates for
testing IMO, and having a "mock gen_server" and other associated tools
at your disposal make this much easier.