On Mon, Jun 8, 2009 at 2:13 PM, David Rosenstrauch<[email protected]> wrote: > Michael Ossareh wrote: >> >> In the case above the code in messageReceived() cannot trigger >> assertion failures, the exception they throw is trapped by the >> framework and JUnit thinks the test passed. I'm using Assert.fail() >> because the test I'm doing isn't part of JUnit's base tests (though I >> understand I should start checking out the hamcrest matchers for my >> tests: >> http://stackoverflow.com/questions/958460/creating-a-assertclass-method-in-junit >> ) however using "normal" assertion fails suffer the same issue, for >> example assertEquals(1, 2) results in the test passing beacause junit >> doesn't ever see the exception. >> >> Clearly you'll see the power of this type of testing, the 20 or tests >> I have to write are all structured the same. Connect client to server, >> either client or server send data, ensure data is rendered same on the >> receiving side. >> >> I'm midway through building a solution to this, however some of it >> really reinventing the wheel and all because >> IoHandlerAdapter.messageReceived / sessionOpened / sessionCreated all >> throw Exception and/or the framework doesn't allow the ability to >> distinguish different Exceptions from this layer. >> >> mike >> > > A couple of suggestions: > > 1) I'd think you really shouldn't need to go through the whole process of > fully starting up the server (with a socket listener listening on a port) > and a client (opening a socket to the server) just to do testing. I don't > know your code so well so perhaps I'm wrong here. But I'd think it should > be sufficient to just *simulate* network communication by using a > DummySession and sending a message down the server's filter chain and seeing > what response - or lack thereof - gets generated. > > 2) If you follow along with that approach, then you won't be in the > situation where your client is performing assertions inside the > messageReceived method (which are obviously getting swallowed). If you look > carefully at the code I posted, you'll see that what I'm doing is to add an > "OutputListener" - a class that I use only to assist with testing - at the > end of my filter chain when I test. The output listener, true to its name, > listens to whatever output/response the server's filter chain processing > generates, and saves it. Once that whole server filter chain interaction is > complete, and I've "saved" the output from my "communication with the > server", only THEN do I go about issuing Asserts to verify that the output > was what I expected. And since these asserts get done outside of the MINA > filter chain processing they never get swallowed. > > > Bottom line: I think you can do any type of JUnit testing you want against > your MINA server, but you need to write your tests differently. > > HTH, > > DR >
Hi David, Thanks for your feedback. I noted your example and my reference to "solution to this" looks not to dissimilar from what you're doing (except I don't want to change the filter chain for fear of creating a difference between prod and dev). The same goes for dummy session. As I get more to grips with MINA I'm sure my assertions as to how to build the tests will change. Cheers, mike -- god loves atheists, Fact: http://www.mrwiggleslovesyou.com/comics/rehab477.jpg
