Michael Ossareh wrote:
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!
There is already a -minimal- DHCP server implemented on top of MINA in
the Apache Directory Server project. It's probably not completed, but
this is a good start, for sure !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
