Thanks, I will be sticking to the 1.0.9 until 1.1 goes to release.  So I'll try 
modifying the RestletServerTestCase, and see what happens.  Thanks. 


>Sam Bao | Software Engineer | Cerner Corporation | 816.201.8242 | [EMAIL 
>PROTECTED] | www.cerner.com

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 15, 2008 9:57 AM
To: discuss@restlet.tigris.org
Subject: Re: Unit testing code coverage

Hi Sam,

I'm only using the current version from the svn trunk. You are right, the 
method does not exist in 1.0

You can try the milestone 1.1 M3 (www.restlet.org/downloads).

Another possibility is to change the line 293: use getConditions and copy all 
attributes from the method parameter to the request Conditions.
If the methods for Reader and writer you can just delete these methods. 
They are only available to ensure, that the entity is not available, if the 
request was a HEAD request

best regards
    Stephan

Bao,Sam schrieb:
> Stephan,
>
> I've just got to looking at the RestletServerTestCase, and it seems I'm 
> getting some errors that I'm thinking may be because I'm using the 1.0.9 
> version.  These are the errors I'm seeing:
>
> 1. Line 293. On the request, I don't have a setConditions() method.
> 2. Line 328 and 357, On my WrapperRepresentation, I lack the getReader() and 
> write(Writer) methods.
>
> Are these methods new to 1.1?  If so, are there deprecated methods in 1.0.9?
>   
>> Sam Bao | Software Engineer | Cerner Corporation | 816.201.8242 | 
>> [EMAIL PROTECTED] | www.cerner.com
>>     
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 14, 2008 6:40 AM
> To: discuss@restlet.tigris.org
> Subject: Re: Unit testing code coverage
>
> Hi Sam,
>
> I've just refactored my JUnit TestCase base class to be used independently of 
> JAX-RS. Take a look at project org.restlet.test (only in SVN trunk), class 
> org.restlet.test.jaxrs.server.RestletServerTestCase. You don't need to take a 
> look into the other classes in this package.
>
> Subclass RestletServerTestCase and wrote test* methods as for every JUnit 
> test. You may use #setUseTcp(true / false) to indicate, if you want real tcp 
> access (slow) or direct application access (sometimes only nearly real). You 
> may also change the initial value in RestletServerTestCase.
> You should use the accessServer methods to access the server.
> So, if you don't understand the result, test with real TCP; if you found a 
> bug in the RestletServerTestCase, let me know, at the best with a test case 
> reproducing it.
>
> The setUp() method automaticly starts the server for every method and
> tearDown() will stop it. So you must ensure to call super.setUp() /
> super.tearDown() if you override them.
>
> Take a look into it and let me know, what is not clear, so I will add more 
> javadoc to methods with not enough javadoc ... I'll be happy about feedback. 
> Perhaps I can not answer the rest of today, but tomorrow I have time for it.
>
> best regards
>    Stephan
>
> Stephan Koops wrote:
>   
>> [...]
>>
>> BTW: It's not required that you use a real TCP client for testing: You can 
>> give the application directly your requests. So you save a LOT of time, 
>> because you save the time to start the TCP-ServerSocket, serializing 
>> requests and so on.
>> I should refactor that out of my JAX-RS test case class, because it is 
>> combined with services for JAX-RS testing.
>>
>> best regards
>>    Stephan

----------------------------------------------------------------------
CONFIDENTIALITY NOTICE This message and any included attachments are from 
Cerner Corporation and are intended only for the addressee. The information 
contained in this message is confidential and may constitute inside or 
non-public information under international, federal, or state securities laws. 
Unauthorized forwarding, printing, copying, distribution, or use of such 
information is strictly prohibited and may be unlawful. If you are not the 
addressee, please promptly delete this message and notify the sender of the 
delivery error by e-mail or you may call Cerner's corporate offices in Kansas 
City, Missouri, U.S.A at (+1) (816)221-1024.

Reply via email to