directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Tests naming
Date Thu, 17 Mar 2005 17:54:31 GMT
Tencé, Vincent wrote:

>I could modify this test to use a precomputed pdu but I still don't get what
>we're trying to test. Before committing anything, I'd like to clarify what
>the intention of the test is. I need your help!
>
>  
>
The intention here is to test round trip encoding and decoding of an 
Abandon message.  However if we use Snacc4J as the control.  If Snacc4J 
decodes the same objects as our decoder then we're good and vice versa.

>We're using AbstractDecoderTestCase, so I assume we're trying to test a
>decoding operation. I've annoted the test with my understanding and some
>questions, pls correct me where I'm missing something.
>
>  
>
Yeah we're testing decoding.  So we're creating an AbandonRequest object 
here, encoding with Snacc4j and attempting to decode with our decoder.  
This is done in the 3 lines below.

>>   public void testAbandonMessage() throws Exception
>>   {
>>       AbandonRequestImpl request = new AbandonRequestImpl( 1 ) ;
>>       request.setAbandoned( 3 ) ;
>>       decode( request ) ;
>>    
>>
>
>At this point, we should have decoded the request using the BERDecoder. The
>result is in the tlvList.
>
>  
>
This decode is tricky - as you can see it the argument is a request 
object so it must be encoded to be decoded.  What decode() is doing is 
encoding using snacc then decoding using our implementation:

    public Tuple decode( Message msg ) throws DecoderException
    {
        // @todo replace this with the Snickers encoder or use serialized
        // PDUs stubs for test cases rather than decoding live.
        Properties env = new Properties();
        env.setProperty( Provider.BERLIB_PROVIDER,
                "org.apache.ldap.common.berlib.snacc.SnaccProvider" );
        MessageEncoder encoder = new MessageEncoder( env );
        decode( encoder.encodeBlocking( msg ) ) ;
       
        return ( Tuple ) tlvList.get( tlvList.size() - 1 ) ;
    }
 

>>       roundTripTest( request ) ;
>>    
>>
>
>This is when I get confused. What is roundTripTest doing exactly? See below
>
>  
>
    public DefaultMutableTupleNode roundTripTest( Message msg ) throws 
Exception
    {
        DefaultMutableTupleNode node = null ;
        ByteBuffer buf1 = encode( msg ) ;
        ttd.decode( buf1 ) ;
        node = ( DefaultMutableTupleNode ) history.getMostRecent() ;
       
        ByteBuffer buf2 = ByteBuffer.allocate( node.size() ) ;
        node.encode( buf2 ) ;
        assertTrue( buf1.equals( buf2 ) ) ;
       
        return node ;
    }
 It is encoding a POJO representing a request into the PDU.  It does 
this using Snacc4J since encoding is not being tested here decoding is.  
It then decodes the buffer produced from the encoding.  At first it 
seems to repeat decode() somewhat but if we look close it is in fact 
using a different decoder: a tuple tree decoder.   This TTD generates an 
object not a TLV tree and uses our decoder implementation not 
Snacc4J's.  The generated object is then encoded into a BB again using 
Snacc4J and compared with the first byte buffer.  So the test is a true 
round trip test. 

>>       assertFalse( tlvList.isEmpty() ) ;
>>    
>>
>
>Is that enough to test that the tlvList is not empty?
>
>  
>
It does make sure that isEmpty() returns false

>>   }
>>    
>>
>
>  
>
>>   public DefaultMutableTupleNode roundTripTest( Message msg ) throws
>>    
>>
>Exception
>  
>
>>   {
>>       DefaultMutableTupleNode node = null ;
>>       ByteBuffer buf1 = encode( msg ) ;
>>    
>>
>
>So we're encoding the msg again
>
>  
>
yep using snacc4j

>>       ttd.decode( buf1 ) ;
>>    
>>
>
>to decode it this time with a TupleTreeDecoder ...
>
>  
>
yep uses [our decoder] -> tlv -> [TTD] -> message object

>>       node = ( DefaultMutableTupleNode ) history.getMostRecent() ;
>>    
>>
>
>... which produces a DefaultMutableTupleNode.
>  
>
yep

>>       ByteBuffer buf2 = ByteBuffer.allocate( node.size() ) ;
>>       node.encode( buf2 ) ;
>>    
>>
>
>Then we encode back to ByteBuffer using the node
>
>  
>
>>       assertTrue( buf1.equals( buf2 ) ) ;
>>    
>>
>
>So what are we testing exactly? Decoding, encoding, both? 
>
Encoding is not being tested that's the control using Snacc4J.  We are 
testing our decoder implemenation and making sure funny stuff does not 
happen by doing a round trip decode, encode, decode compare.

>What is the
>relation with the BERDecoder and the assert in testAbandonMessage()?
>  
>
I think I was just making sure that something decoded from the first 
decode( request ); call.  That's about it.  It's just to make sure we 
decoded something, anything.

>>       return node ;
>>   }
>>    
>>
>
>Thanks,
>-- Vincent
>
>  
>
>>-----Original Message-----
>>From: Alex Karasulu [mailto:aok123@bellsouth.net]
>>Sent: March 16, 2005 1:53 PM
>>To: Apache Directory Developers List
>>Subject: Re: Tests naming
>>
>>
>>Change things as you like.  I will follow your lead with the 
>>test case 
>>naming and all.  
>>
>>This test ....
>>
>>   public void testAbandonMessage() throws Exception
>>   {
>>       AbandonRequestImpl request = new AbandonRequestImpl( 1 ) ;
>>       request.setAbandoned( 3 ) ;
>>       decode( request ) ;
>>       roundTripTest( request ) ;
>>       assertFalse( tlvList.isEmpty() ) ;
>>   }
>>
>>... generates an AbandonRequest PDU testing the encoding decoding 
>>projects.  Take a look at the abstract test class and the functions 
>>built into it for convenience.
>>
>>Let me know if you need help,
>>Alex
>>
>>    
>>
>
>  
>


Mime
View raw message