Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: domain of aok123@bellsouth.net
 designates 205.152.59.65 as permitted sender)
Message-ID: <42098EAB.3@bellsouth.net>
Date: Tue, 08 Feb 2005 23:16:43 -0500
From: Alex Karasulu <aok123@bellsouth.net>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: Apache Directory Developers List <directory-dev@incubator.apache.org>
Subject: Re: Getting rid of snacc dependency in snickers test cases
References: <42083FCD.6060500@videotron.ca> <420989C1.9090404@videotron.ca>
In-Reply-To: <420989C1.9090404@videotron.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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