directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Getting rid of snacc dependency in snickers test cases
Date Wed, 09 Feb 2005 04:16:43 GMT
Vincent Tence wrote:

> Status
> ------
>
> A lot of the test cases in svn have been migrated to using 
> pre-computed PDUs. This goes for encoders as well as decoders tests. 
> Tests have also been simplified to rely on the equals() implementation 
> of message classes - it'll test it for the same price.
>
> However, some of the test cases are causing trouble. The offending 
> test cases have an TODO: tag that will help identify them. For those 
> test, the migrated version is in comment until I can find out what's 
> going on.
>
> So far here's what I've learned about tests failing when migrated:
>
> 1. All decoder tests that use a response containing a BUSY result code 
> fail. The decoded message shows a SUCCESS result code.

Something must be wrong with type safe enum ResultCodeEnum somewhere.

>
> 2. ModifyRequestTest fails for an unknown reason

Any ideas on how we may isolate the problem here?

>
> 3. I'm not sure how to migrate the SearchRequestTest

What's presenting a problem?

>
> 4. ExtendedResponseEncoderTest is a copy of ExtendedRequestEncoderTest 
> instead of a test of its own.

Np just blow it away if you don't have time to implement the test.

>
> 5. Encoders generate PDUs that look equivalent yet are different from 
> snacc one's - a CHOICE order maybe?

Yeah there are differences in the way elements are order like the order 
of attributes in a search entry response.  Snacc uses a HashMap to store 
these where we use an ArrayList.   Hence the difference in order.  The 
only way to conduct tests halfway properly is to put elements into a Map 
and make sure both elements exist in both PDUs.  Comparisons based on 
order will fail.

<snip/>

-Alex


Mime
View raw message