[erlang-questions] Testing a large, heterogeneous system
Sat Jul 27 12:15:03 CEST 2013
If you want to limit setup/teardown of the external parts (like your custom
hardware), meck  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 
has some very powerful tools for testing states and reasoning about what
should be valid before and after state transitions. Checkout proper_statem
 and this  example of a very useful test implementing the
On Thu, Jul 25, 2013 at 4:46 PM, David Welton <davidnwelton@REDACTED>wrote:
> 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
> 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
> Sorry if this is all a bit muddled - any advice is appreciated!
> Thank you,
> David N. Welton
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions