On Mon, Jun 8, 2009 at 3:10 PM, Emmanuel Lecharny<[email protected]> wrote: > Michael Ossareh wrote: >> >> 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. >> > > I would add to the very sensitive proposals David have suggested that > whatever you do in your unit tests, trying to keep them close to what you > will have in prod by simulating the full stack (ie, with sockets and server) > is probably impossible : it will just test that the loopback interface works > well, with time conditions totally different to what you will have in prod > anyway.
This is a valid point for sure. In particular I'm trying to test some decoders and encoders that I've written to implement a custom binary protocol. It wasn't clear to me, and I appreciate that MINA is work in progress, how to get an entity to send an object through a filter chain, and then another entity decode that object. As an easier way of doing this I decided to fire up a server and a client. As far as my testing goes I now have a nice black box solution, the server and client deal with call backs where the assertions are trapped in the case of a failure and reported back once outside of the MINA framework. > > This is what is difficult when it comes to test a server : unit tests are > just good enough to check the internal logic (ie, the encoder/decoder, the > handler), but you need to build a bench with a real server, real injectors, > etc. > > Note that testing your application with real sockets is also good to have, > as you may encounter some weird conditions too. > > Thanks for using MINA, btw ! I'm extremely thankful for MINA! A number of years ago I tried to write an opensource java dhcpd - the point being to have web service calls at particular parts of the state machine to do things like mac address authentication, etc. Now with MINA I'm sure I can ressurect that project when I find some spare time! > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > > -- god loves atheists, Fact: http://www.mrwiggleslovesyou.com/comics/rehab477.jpg
