Getting rid of snacc dependency in snickers test cases

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

I'm in the process of migrating Snickers test cases to using 
pre-computed pdus rather than relying on Snacc provider to compute pdus 
on the fly.

The pre-computed pdus are generated using a helper class that I want to 
keep outside the snickers subproject, for breaking the snickers -> snacc 
dependency. I've not found a definitive home for it, but I was thinking 
of putting it within the test folder of the snacc component. WDYT?

You can use this helper class in one of the following ways:

1. Serialize a message content to XML using XStream and feed it to the 
PDUGenerator (not sure this is any useful after all)
2. Copy and paste your message building code in the PDUGenerator class
(KISS)

In both cases the end result is the PDU string that you can just paste 
to your snickers test case:

byte[] req = new byte[] <paste here>


If we're ok with this, I'll proceed and update all the test cases.

- Vincent

Re: Getting rid of snacc dependency in snickers test cases

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

Alex Karasulu wrote:

 > Let's make sure the snacc4j jar is not referenced
> anywhere but in the snacc-provider.  You probably did this already.  

Right. It's not referenced in apache-provider anymore.

- Vincent

Re: Getting rid of snacc dependency in snickers test cases

[Alex Karasulu <ao...@bellsouth.net>]

Vincent Tence wrote:

> Just to let you know that all test cases have been migrated by now. 
> This means we do not depend on snacc4j anymore.
>
Hip hip hurray!  Let's make sure the snacc4j jar is not referenced 
anywhere but in the snacc-provider.  You probably did this already.  
Anyhow thanks for groking this - you did a great job.

Alex

> Cheers,
> - Vincent
>
> Vincent Tence wrote:
>
>> I'm in the process of migrating Snickers test cases to using 
>> pre-computed pdus rather than relying on Snacc provider to compute 
>> pdus on the fly.
>>
>> The pre-computed pdus are generated using a helper class that I want 
>> to keep outside the snickers subproject, for breaking the snickers -> 
>> snacc dependency. I've not found a definitive home for it, but I was 
>> thinking of putting it within the test folder of the snacc component. 
>> WDYT?
>>
>> You can use this helper class in one of the following ways:
>>
>> 1. Serialize a message content to XML using XStream and feed it to 
>> the PDUGenerator (not sure this is any useful after all)
>> 2. Copy and paste your message building code in the PDUGenerator class
>> (KISS)
>>
>> In both cases the end result is the PDU string that you can just 
>> paste to your snickers test case:
>>
>> byte[] req = new byte[] <paste here>
>>
>>
>> If we're ok with this, I'll proceed and update all the test cases.
>>
>> - Vincent
>
>
>

Re: Getting rid of snacc dependency in snickers test cases

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

Just to let you know that all test cases have been migrated by now. This 
means we do not depend on snacc4j anymore.

Cheers,
- Vincent

Vincent Tence wrote:
> I'm in the process of migrating Snickers test cases to using 
> pre-computed pdus rather than relying on Snacc provider to compute pdus 
> on the fly.
> 
> The pre-computed pdus are generated using a helper class that I want to 
> keep outside the snickers subproject, for breaking the snickers -> snacc 
> dependency. I've not found a definitive home for it, but I was thinking 
> of putting it within the test folder of the snacc component. WDYT?
> 
> You can use this helper class in one of the following ways:
> 
> 1. Serialize a message content to XML using XStream and feed it to the 
> PDUGenerator (not sure this is any useful after all)
> 2. Copy and paste your message building code in the PDUGenerator class
> (KISS)
> 
> In both cases the end result is the PDU string that you can just paste 
> to your snickers test case:
> 
> byte[] req = new byte[] <paste here>
> 
> 
> If we're ok with this, I'll proceed and update all the test cases.
> 
> - Vincent

Re: Getting rid of snacc dependency in snickers test cases

[Alex Karasulu <ao...@bellsouth.net>]

Vincent Tence wrote:

>>> 2. ModifyRequestTest fails for an unknown reason
>>
>>
>>
>> Any ideas on how we may isolate the problem here?
>
>
> If fact the reason is unknown cause I did not investigate it yet :)

:)

>
>>> 3. I'm not sure how to migrate the SearchRequestTest
>>
>>
>>
>> What's presenting a problem?
>
>
> This one seems complex so I leave it until all other issues are resolved.

ok that's reasonable search (esp. filter) is by far the most complex

-Alex

Re: Getting rid of snacc dependency in snickers test cases

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

>> 2. ModifyRequestTest fails for an unknown reason
> 
> 
> Any ideas on how we may isolate the problem here?

If fact the reason is unknown cause I did not investigate it yet :)

>> 3. I'm not sure how to migrate the SearchRequestTest
> 
> 
> What's presenting a problem?

This one seems complex so I leave it until all other issues are resolved.

>>
>> 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.

Alright.

- Vincent

Re: Getting rid of snacc dependency in snickers test cases

[Alex Karasulu <ao...@bellsouth.net>]

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

Re: Getting rid of snacc dependency in snickers test cases

[Alex Karasulu <ao...@bellsouth.net>]

Vincent Tence wrote:

> In this case, I will manually update the attributes order in the 
> pre-computed PDUs to match the order produced by snickers. Any objection?
>
Nope. 

Thanks again,
Alex

Re: Getting rid of snacc dependency in snickers test cases

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

In this case, I will manually update the attributes order in the 
pre-computed PDUs to match the order produced by snickers. Any objection?

- Vincent

Alex Karasulu wrote:
> Vincent Tence wrote:
> 
>>> 5. Encoders generate PDUs that look equivalent yet are different from 
>>> snacc one's - a CHOICE order maybe?
>>
>>
>>
>> I meant SET not CHOICE
> 
> 
> Yep I gathered that.  The issue here is with SET there is no requirement 
> for perserving order.  Snacc jumbles things up unpredicatably due to the 
> HashMap it uses for storing a SET.  Take a look at the Snacc generated 
> code for specific constructs and you'll see just how she behaves.
> 
> Cheers,
> Alex

Re: Getting rid of snacc dependency in snickers test cases

[Alex Karasulu <ao...@bellsouth.net>]

Vincent Tence wrote:

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

Yep I gathered that.  The issue here is with SET there is no requirement 
for perserving order.  Snacc jumbles things up unpredicatably due to the 
HashMap it uses for storing a SET.  Take a look at the Snacc generated 
code for specific constructs and you'll see just how she behaves.

Cheers,
Alex

Re: Getting rid of snacc dependency in snickers test cases

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

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

I meant SET not CHOICE

Re: Getting rid of snacc dependency in snickers test cases

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

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.

2. ModifyRequestTest fails for an unknown reason

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

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

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

I'm currently investigated #1. For #5, my plan is to check the RFC 
defining the message ASN1 structures to see if they're indeed equivalent.

- Vincent

Vincent Tence wrote:
> I'm in the process of migrating Snickers test cases to using 
> pre-computed pdus rather than relying on Snacc provider to compute pdus 
> on the fly.
> 
> The pre-computed pdus are generated using a helper class that I want to 
> keep outside the snickers subproject, for breaking the snickers -> snacc 
> dependency. I've not found a definitive home for it, but I was thinking 
> of putting it within the test folder of the snacc component. WDYT?
> 
> You can use this helper class in one of the following ways:
> 
> 1. Serialize a message content to XML using XStream and feed it to the 
> PDUGenerator (not sure this is any useful after all)
> 2. Copy and paste your message building code in the PDUGenerator class
> (KISS)
> 
> In both cases the end result is the PDU string that you can just paste 
> to your snickers test case:
> 
> byte[] req = new byte[] <paste here>
> 
> 
> If we're ok with this, I'll proceed and update all the test cases.
> 
> - Vincent

Re: Getting rid of snacc dependency in snickers test cases

[Alex Karasulu <ao...@bellsouth.net>]

Vincent Tence wrote:

> I noticed in the process that Snacc encoded PDUs are a bit different 
> from Snickers encoded PDUs. The snacc ones end with an empty sequence of
>
> A0 00
>
> I think it's not an issue and I'm removing that ending sequence from 
> the precomputed generated PDUs (and ajusting the PDU size 
> accordingly). Can you confirm this is ok?

I forget exactly what this is for.  It might be an empty set of controls 
for the LDAP PDU.  Snacc4J if I remember creates this in advance before 
it knows it has a valid control or not.  I may be totally off here 
though.  Regardless of exactly what it is its extra Snacc4J verbosity 
that is not needed for those PDUs.  If I'm wrong we can always add them 
again.

Go ahead and just build the PDU without the extra 'A0 00'.

Thanks
Alex

<snip/>

Re: Getting rid of snacc dependency in snickers test cases

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

I noticed in the process that Snacc encoded PDUs are a bit different 
from Snickers encoded PDUs. The snacc ones end with an empty sequence of

A0 00

I think it's not an issue and I'm removing that ending sequence from the 
precomputed generated PDUs (and ajusting the PDU size accordingly). Can 
you confirm this is ok?

Thanks,
- Vincent

Alex Karasulu wrote:
> Vincent Tence wrote:
> 
>> I'm in the process of migrating Snickers test cases to using 
>> pre-computed pdus rather than relying on Snacc provider to compute 
>> pdus on the fly.
> 
> 
> Awesome!  I'd love to make sure the word Snacc is no where in site even 
> in test case code.
> 
>>
>> The pre-computed pdus are generated using a helper class that I want 
>> to keep outside the snickers subproject, for breaking the snickers -> 
>> snacc dependency. I've not found a definitive home for it, but I was 
>> thinking of putting it within the test folder of the snacc component. 
>> WDYT?
> 
> 
> Sure that could work totally.  It's used for generating test PDUs for 
> tests and is never meant to be deployed in any artifact.  Yeah thinking 
> it through now it sounds just fine.  Go for it!
> 
>> You can use this helper class in one of the following ways:
>>
>> 1. Serialize a message content to XML using XStream and feed it to the 
>> PDUGenerator (not sure this is any useful after all)
> 
> 
> You're always using the cool new stuff from the haus.  You make me jealous.
> 
>>
>> 2. Copy and paste your message building code in the PDUGenerator class
>> (KISS)
> 
> 
> Sure that's mui biene.
> 
>>
>> In both cases the end result is the PDU string that you can just paste 
>> to your snickers test case:
>>
>> byte[] req = new byte[] <paste here>
>>
> Excellent this really is all we need at the end of the day.  Great job 
> here dude.  Also you made it in time to play with some more serious 
> ASN.1 restructuring.
> 
>> If we're ok with this, I'll proceed and update all the test cases.
> 
> 
> Yeah we're better than good with this so make your changes at will and 
> join me in the rewrite branch :)
> 
> Good work!  I hope it lead to a better understanding of the ASN.1 code 
> base.
> 
> Thanks much,
> Alex
> 
> 

Re: Getting rid of snacc dependency in snickers test cases

[Alex Karasulu <ao...@bellsouth.net>]

Vincent Tence wrote:

> I'm in the process of migrating Snickers test cases to using 
> pre-computed pdus rather than relying on Snacc provider to compute 
> pdus on the fly.

Awesome!  I'd love to make sure the word Snacc is no where in site even 
in test case code.

>
> The pre-computed pdus are generated using a helper class that I want 
> to keep outside the snickers subproject, for breaking the snickers -> 
> snacc dependency. I've not found a definitive home for it, but I was 
> thinking of putting it within the test folder of the snacc component. 
> WDYT?

Sure that could work totally.  It's used for generating test PDUs for 
tests and is never meant to be deployed in any artifact.  Yeah thinking 
it through now it sounds just fine.  Go for it!

> You can use this helper class in one of the following ways:
>
> 1. Serialize a message content to XML using XStream and feed it to the 
> PDUGenerator (not sure this is any useful after all)

You're always using the cool new stuff from the haus.  You make me jealous.

>
> 2. Copy and paste your message building code in the PDUGenerator class
> (KISS)

Sure that's mui biene.

>
> In both cases the end result is the PDU string that you can just paste 
> to your snickers test case:
>
> byte[] req = new byte[] <paste here>
>
Excellent this really is all we need at the end of the day.  Great job 
here dude.  Also you made it in time to play with some more serious 
ASN.1 restructuring.

> If we're ok with this, I'll proceed and update all the test cases.

Yeah we're better than good with this so make your changes at will and 
join me in the rewrite branch :)

Good work!  I hope it lead to a better understanding of the ASN.1 code base.

Thanks much,
Alex