It is a challenge to write test cases for software with blocking operations, i.e. operations that do not return until data become available. One should prevent the test case itself to block, whereas at the same time, one wants to test the blocking behaviour. Therefore, the standard solution is to write concurrent test cases, each call in the test case executed by a newly spawned process, together with a lot of boilerplate code. Manually crafted test cases can check that blocking calls are indeed blocked and unblocked as expected. Writing such test cases is error-prone and covering all interesting cases requires a lot of manually written tests.
By using QuickCheck?s state machines one can automatically generate the test cases from a specification, but also here the boilerplate code is needed. We demonstrate that by using the component library in QuickCheck, an extension of the state machine formalism, the boilerplate code is no longer needed. Using the component library results in clear and concise specifications that are effectively used for testing. By using this new library, software with blocking operations can be tested much more thoroughly than by using a manual test approach.
[1]
John Hughes,et al.
Testing telecoms software with quviq QuickCheck
,
2006,
ERLANG '06.
[2]
Koen Claessen,et al.
QuickCheck: a lightweight tool for random testing of Haskell programs
,
2000,
ICFP.
[3]
John Hughes,et al.
QuickCheck Testing for Fun and Profit
,
2007,
PADL.
[4]
Roger Duke,et al.
A UML approach to the generation of test sequences for Java-based concurrent systems
,
2005,
2005 Australian Software Engineering Conference.
[5]
Koen Claessen,et al.
Finding race conditions in Erlang with QuickCheck and PULSE
,
2009,
ICFP.