Thursday 2 August 2012

A simple way to test distributed applications

So, testing distributed applications is not easy, we all know it.
Too many variants to take in considerations which usually lead to an high instability of the tests.

Let say we have a front end application sending messages to a distribution engine which then forward the messages to other remote destinations. Sounds familiar?

OK so, how you test that messages travelling correctly trough all the predefined servers?

What if I want to keep my tests independent from any integration framework?

My solution is in the logs.
Why not rely on the logs to prove that your application is working as expected?

Logs are often underrated for performance/acceptance/smoke tests, but if correctly written, they can provide all the information you need to measure the status of your software at any point of its execution.

Testing relying on logs is a non intrusive way to test and no performances or anything will be affected. Applying this concept to an hypothetical integration test it's easy (at least in UNIX environments :) ), thanks to libraries like Grep4j:


import static org.grep4j.core.Grep4j.grep;
import static org.grep4j.core.Grep4j.regularExpression;
import static org.grep4j.core.fluent.Dictionary.on;
import static org.grep4j.core.fluent.Dictionary.executing;
...

@Test
public void aCreateMessageShouldPassThroughAllTheFinalDestinations() {
  List profiles =  Arrays.asList(distributionServerLog(),
                                 destination1ServerLog(),
                                 destination2ServerLog(),
                                 destination3ServerLog());

assertThat(executing(grep(regularExpression("MessageId(.*)Received"), on(profiles))).totalLines(), is(4));

}


As you can see, in a very simple way you have an efficient end-to-end test across different machines.

I think this approach is also a good option when you want to build acceptance or regression tests around legacy applications. You can treat your legacy app as a black box and just test the expected output in the log. 

Finally, I reckon this way of test will force the developers to standardize and uniform the way to log in the code which is always good :)

2 comments:

  1. if company is willing then we have spunk software.

    anyways thanks for highlighting and added in my blog.

    Thanks
    Prasanth
    http://prasanthaboutjava.blogspot.co.uk/

    ReplyDelete
  2. Thanks Prasanth for adding it in your blog.
    Spunk is a good commercial software, but it's a tool for Operation and developers cannot use it easily to automate tests based on logs.
    In my company we use Grep4j to run smoke tests, performance tests and acceptance tests, all triggered by timed Jenkins jobs.

    ReplyDelete