Hi all, so we have more and more ported drivers, which is a good thing. However all of these are mostly not covered by unit- or integration-tests. I wouldn’t want to release them like that.
So I was thinking how we can write tests for these in a universal way where you don’t have to learn a completely new approach to testing for every driver. The idea I had, and for which would like your feedback, would be more an Integration-Testsuite. We already have a XML based Unit-Test framework for the parsers which help get the messages themselves correct and can prove the parsers and serializers are doing what we want them too … here a lot more tests could be created. Based on this Framework I would like to build something that takes things one step further. There is one transport called “test” … this allows passing bytes into a pipeline and making assertions to both ends of the Netty pipelines. Also does it allow to read output from the pipeline. I would now like to combine the XML notation used in the unit-test framework to specify the expected interaction with the driver … in this we could treat one testcase as a sequence of “send” and “expect” elements. The framework would step through each element from the top to the bottom. If it gets a “send” element it will parse the XML message, serialize it and send those bytes to the pipeline. If it processes an “expect” it will wait till it gets a byte[] from the pipeline, parse it, serialize it as XML and compare that to the expected xml in the “expected” tag. I think with a setup like this we could produce a lot of integration-tests that should get the coverage up pretty fast and it should help with defining scenarios for bug reports pretty easily. What do you think? Chris
