Thank you Lukas!<br><br>That was the realization I was coming to about common_test that you said perfectly: it's for distributing tests, not testing distributed applications.<br><br>Looks like I'll be writing the infrastructure myself.  At least I have the slave and rpc modules to help me out.<br>
<br>-Garret<br><br><br><div class="gmail_quote">On Tue, Dec 20, 2011 at 4:47 AM, Lukas Larsson <span dir="ltr"><<a href="mailto:lukas@erlang-solutions.com">lukas@erlang-solutions.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello!<br>
<br>
The ct_master module is not really meant to test distributed<br>
applications, but rather to distribute your tests. It helps you when<br>
you have 1000 tests to run, but can only finish 500 per day and you<br>
need to run all of them each day.<br>
<br>
When testing distributed application with common_test, I use the<br>
ct_slave (or just even slave) module and configure slaves to be<br>
started on node X and Y and then run test suites on node Z which<br>
trigger test behavior either through rpc or SIP och whatever interface<br>
you want to test. Serializing test calls and making sure that no test<br>
cases interfere with each other I do in the testcase and suite as I<br>
would with a non-distributed application.<br>
<br>
Lukas<br>
<div><div class="h5"><br>
On Tue, Dec 20, 2011 at 1:56 AM, Garret Smith <<a href="mailto:garret.smith@gmail.com">garret.smith@gmail.com</a>> wrote:<br>
> I just finished setting up an automated test suite for my distributed<br>
> application using the common_test "Large Scale Testing" support.  It was<br>
> rough, but *almost* works.  It starts up 2 local nodes, starts my app on<br>
> both nodes, runs a few test cases from my suite on node1, a second batch of<br>
> cases on node2, then yet another batch of cases on node1.<br>
><br>
> The test cases are designed to work by contacting the distributed app on<br>
> node1, modifying it's state through the API, then contacting the app on<br>
> node2 to verify that the state changes are reflected there, then repeating<br>
> from the perspective of node2.<br>
><br>
> sample test spec, invoked with ct_master:run/1<br>
><br>
> {logdir, "../logs"}.<br>
><br>
> {alias, testdir, "."}.<br>
><br>
> {init, [n1, n2], {node_start, [{erl_flags, "-pa ../../ebin"},<br>
> {monitor_master, true}]}}.<br>
><br>
> {merge_tests, false}.<br>
><br>
> {cases, n1, testdir, distributed_SUITE, [create_table, insert_1]}.<br>
> {cases, n2, testdir, distributed_SUITE, [read_1, update_2]}.<br>
> {cases, n1, testdir, distributed_SUITE, [read_2]}.<br>
><br>
><br>
><br>
> Now that my basic setup using ct_master is working, I notice that sometimes<br>
> the tests fail because I cannot depend on the batches being executed in<br>
> sequence.  ct_master executes the test cases in parallel on the two nodes.<br>
> I could continue down this path by adding synchronization somehow, but I<br>
> feel that I am not really using ct_master in the way it was intended.<br>
><br>
> Has anyone on the list had experience writing an automated test suite where<br>
> the SUT is a single app running on a cluster of nodes?  Were you able to do<br>
> this with common_test, or did you end up rolling your own framework?<br>
><br>
> Thanks!<br>
><br>
> -Garret Smith<br>
><br>
</div></div>> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
</blockquote></div><br>