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 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 !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
