Nov 11, 2009
Published in: Testing articles
I got this e-mail from a reader today:
I don’t know how can I test asynchronous systems. We develop Voice Communication System applications and everything is based on (asynchronous) request-response. I’m trying to write unit tests for such application […] What is the preferable way to do it? Here I think I must test the whole system chain…
Asynchronous systems seem to be one of the most problematic areas for automated testing. The issue with this is that often too many things get tested at the same time. Think about whether you testing the business logic of the process, technical infrastructure integration or the fact that all the components can talk to each-other.
Most asynchronous systems I’ve seen have some sort of pre-validation of the request, then asynchronous dispatching, then processing and publishing the reply (either saving it to the database or pushing on a message queue, for example). Each of these steps might have some business logic which should be tested. My advice is to:
Moving down from business over infrastructure to end-to-end tests, I would normally expect to see the number of tests decrease significantly and time to execute individual tests increase significantly. By executing complicated business logic tests against in-memory synchronous structures you will get the benefit of faster test feedback and better stability.
What you definitely should not be doing is running functional tests throughout the whole pipeline. Such tests will be very complicated and brittle.
Get practical knowledge and speed up your software delivery by participating in hands-on, interactive workshops:
Get future articles, book and conference discounts by e-mail.