[erlang-questions] Testing a large, heterogeneous system

[Gustav Simonsson]

Hi,

If you want to limit setup/teardown of the external parts (like your custom
hardware), meck [1] is a great tool for mocking
all or a subset of external dependencies.

Without knowing the internals of your system it's hard to give specific
advice, but if you have a bunch of state-full stuff proper [2]
has some very powerful tools for testing states and reasoning about what
should be valid before and after state transitions. Checkout proper_statem
[3] and this [4] example of a very useful test implementing the
proper_statem callbacks.

Cheers,
Gustav Simonsson

[1] https://github.com/eproxus/meck
[2] http://proper.softlab.ntua.gr/
[3] http://proper.softlab.ntua.gr/doc/proper_statem.html
[4] https://github.com/wooga/locker/blob/master/src/locker_proper.erl


On Thu, Jul 25, 2013 at 4:46 PM, David Welton <davidnwelton@REDACTED>wrote:

> Hi,
>
> I'm looking for ideas on testing a system we're developing.
>
> Currently we have nothing, so anything is better than that.  We're
> looking to get the most 'bang for our buck', so to speak, so tests
> that cover, even if roughly, more code are going to be better in some
> ways that something that's too specific to a small part of the system.
>
> Erlang, in our project, sits in the middle: it offers a web interface
> that uses lots of Javascript via Chicago Boss, manages some web
> sockets, talks to a database (Postgres), interacts with several C
> nodes, and also manages various external programs via erlexec and
> open_port.  To add some complexity, specialized hardware is involved
> and dealt with via the C programs/nodes.
>
> I read the chapter on Common Test in Learn You Some Erlang, and that
> looks like a pretty good platform.  What I'm struggling with is what
> sort of strategy to use to test the whole thing.
>
> Things I'm dubious about:
>
> * How to handle the external bits?  It'd be nice if the tests could be
> run on a developer's machine without requiring the hardware.  But I
> could also see something rigged up to interact with the hardware being
> valuable as well.  Forced to choose, I'd go with the former, I think.
>
> * The interaction with the hardware stuff is kind of complex and
> involves a lot of state, and messages going back and forth and input
> from the user via the web, storing stuff in the database and so on.
> The web portions of things... maybe could be tested in isolation to a
> certain point, but the sequence of messages going back and forth is
> tricky and probably the place where tests will give us the most
> benefits.   I'm used to tests that try and test fairly small chunks of
> a system, but I'm not sure how feasible that is in this case - the
> setup and teardown might involve a lot of stuff just for a small
> test...
>
> Sorry if this is all a bit muddled - any advice is appreciated!
>
> Thank you,
> --
> David N. Welton
>
> http://www.welton.it/davidw/
>
> http://www.dedasys.com/
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130727/e9c3417d/attachment.htm>