Test Design

[Berin Loritsch <bl...@d-haven.org>]

The thread on test naming got my memory jogged.  A number of the tests 
require a socket set up and things shoved through it to make it work.  
That is really integration testing, not unit testing.  Integration tests 
are important, but unit tests are what needs to be run as part of 
building a project.  Usually it consists of encoding a message, sending 
it over the wire and decoding it on the other side.

What would be better is if we could compare the encoded set of bytes 
(using a ByteInputStream and a ByteOutputStream) and compare the set to 
what the properly encoded message should look like.  Similarly, on the 
decode side start out with the byte array of the encoded message and 
have the system decode it on the other side.

If the code does not allow us to pass in our own streams then that would 
be a point for refactoring to make the system more friendly to testing.  
That would also releave the need to poke holes in personal firewalls 
just so the test can run (something Linux developers need to do).  It 
also reduces the points of failure and makes it plainly obvious what is 
an accurately encoded messgae.  Hopefully it will also avoid the problem 
where the library is consistent with itself but not with production LDAP 
servers.

Re: Test Design

[Berin Loritsch <bl...@d-haven.org>]

Enrique Rodriguez wrote:

> Berin Loritsch wrote:
> <snip/>
>
>> If the code does not allow us to pass in our own streams then that 
>> would be a point for refactoring to make the system more friendly to 
>> testing.  That would also releave the need to poke holes in personal 
>> firewalls just so the test can run (something Linux developers need 
>> to do).  It also reduces the points of failure and makes it plainly 
>> obvious what is an accurately encoded messgae.  Hopefully it will 
>> also avoid the problem where the library is consistent with itself 
>> but not with production LDAP servers.
>
>
> Is there anything we can do with MINA here, perhaps a test mode or a 
> filter that effectively disables port binding and can shunt traffic to 
> test code?  MINA seems the obvious place to put in this sort of test 
> support.
>

Keep in mind that there are unit tests and integration tests.  Unit 
tests are designed to test just the library such as the asn1 
encoding/decoding.  Integration tests would include MINA as part of the 
system to simulate a complete working system.  The unit tests ensure 
that the library is consistent with what we expect it to be.  The 
integration tests ensure that no issues are introduced when we wire the 
different components together.

For the sake of integration testing, I would like to be able to skip the 
port binding if it is possible--but it is less critical.

For the sake of unit testing, it is a question of isolating just the 
item under test.

Re: Test Design

[Trustin Lee <tr...@gmail.com>]

Hi,

On Thu, 17 Mar 2005 14:03:50 -0500, Enrique Rodriguez
<er...@apache.org> wrote:
> Berin Loritsch wrote:
> <snip/>
> > If the code does not allow us to pass in our own streams then that would
> > be a point for refactoring to make the system more friendly to testing.
> > That would also releave the need to poke holes in personal firewalls
> > just so the test can run (something Linux developers need to do).  It
> > also reduces the points of failure and makes it plainly obvious what is
> > an accurately encoded messgae.  Hopefully it will also avoid the problem
> > where the library is consistent with itself but not with production LDAP
> > servers.
> 
> Is there anything we can do with MINA here, perhaps a test mode or a
> filter that effectively disables port binding and can shunt traffic to
> test code?  MINA seems the obvious place to put in this sort of test
> support.

To test messages, you can just call encode(...) and decode(...)
method.  ProtocolEncoderOuput, ProtocolDecoderOutput, and
ProtocolSession should be mock objects in this case.

To test ProtocolHandlers, you can just call their event handler
methods.  Of course, you'll have to use mock objects heavily.

Trustin.
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/

Re: Test Design

[Enrique Rodriguez <er...@apache.org>]

Berin Loritsch wrote:
<snip/>
> If the code does not allow us to pass in our own streams then that would 
> be a point for refactoring to make the system more friendly to testing.  
> That would also releave the need to poke holes in personal firewalls 
> just so the test can run (something Linux developers need to do).  It 
> also reduces the points of failure and makes it plainly obvious what is 
> an accurately encoded messgae.  Hopefully it will also avoid the problem 
> where the library is consistent with itself but not with production LDAP 
> servers.

Is there anything we can do with MINA here, perhaps a test mode or a 
filter that effectively disables port binding and can shunt traffic to 
test code?  MINA seems the obvious place to put in this sort of test 
support.

-enrique

Re: Test Design

[Berin Loritsch <bl...@d-haven.org>]

Vincent Tence wrote:

>>The thread on test naming got my memory jogged.  A number of the tests
>>require a socket set up and things shoved through it to make it work.
>>    
>>
>
>Are you talking about the asn1 tests with Snacc4j dependency or something
>totally different? I'm suspecting the later
>
>  
>
I can't remember exactly where they were.  I could have sworn it had to 
do with the asn1 tests, but
I don't know if it was with the Snacc4j integration or Snickers.  Its 
been a while since I had time to
jump in the code and I'm going on memory hear.

Re: Test Design

[Vincent Tence <vt...@videotron.ca>]

> The thread on test naming got my memory jogged.  A number of the tests
> require a socket set up and things shoved through it to make it work.

Are you talking about the asn1 tests with Snacc4j dependency or something
totally different? I'm suspecting the later

> That is really integration testing, not unit testing.  Integration tests
> are important, but unit tests are what needs to be run as part of
> building a project.

I couldn't agree more

> Usually it consists of encoding a message, sending
> it over the wire and decoding it on the other side.
>
> What would be better is if we could compare the encoded set of bytes
> (using a ByteInputStream and a ByteOutputStream) and compare the set to
> what the properly encoded message should look like.  Similarly, on the
> decode side start out with the byte array of the encoded message and
> have the system decode it on the other side.
>
> If the code does not allow us to pass in our own streams then that would
> be a point for refactoring to make the system more friendly to testing.

+1

> That would also releave the need to poke holes in personal firewalls
> just so the test can run (something Linux developers need to do).  It
> also reduces the points of failure and makes it plainly obvious what is
> an accurately encoded messgae.  Hopefully it will also avoid the problem
> where the library is consistent with itself but not with production LDAP
> servers.

+1