Re: Serializing test case classes

[Nicholas Lesiecki <nd...@yahoo.com>]

(Sorry I'm late in jumping onto this thread)

This seems like a good idea because it will finally eliminate the
counterintuitive behavior of the test state not persisting from the client
to the server. However, will the test be reserialized and sent back to the
client to be finished? It seems like the process should be symmetrical...

> It might be good to keep the
> current behaviour as a fallback if the test case is not serializable.

I'm -1 for having two modes. I doubt many users are taking advantage of the
non-Cactus suite method of running tests, and requiring them to make the
tests serializable seems like a small burden.


Cheers,
Nick

On 10/19/03 7:45 AM, "Christopher Lenz" <cm...@gmx.de> wrote:

> Vincent Massol wrote:
>> I'd like to propose a change of implementation for Cactus 1.6. I'd like
>> to serialize test case classes on the client side and pass them to the
>> server side, instead of recreating the test case class on the server
>> side.
>> 
>> Benefits? This will allow several new use cases, such as parametrized
>> tests. Imagine the follow test case:
>> 
>> public class MyTest extends TestCase
>> {
>>   private int someData;
>> 
>>   MyTest(int data)
>>   {
>>     super("testParamData");
>>     this.someData = data;
>>   }
>> 
>>   public static Test suite()
>>   {
>>     TestSuite suite = new TestSuite();
>>     suite.addTest(new MyTest(10));
>>     suite.addTest(new MyTest(20));
>>     return ServletTestSuite(suite);
>>   }
>> }
>> 
>> This will not work with the current Cactus.
>> 
>> What do you think?
> 
> This looks like a good idea IMHO. We would also no longer need to
> explicitly pass the test class and method names if using serialization,
> right?
> 
> However, the test cases will need to implement Serializable, so the
> whole thing is not totally transparent. We can mark the ServletTestCase,
> FilterTestCase and JspTestCase as serializable, but user provided normal
> JUnit test cases that are executed in the context of a ServletTestSuite
> would need to be made serializable by the user (i.e., the above example
> is lacking the "implements Serializable").
> 
> In addition, this would require JUnit 3.8, because previous versions do
> not provide a parameter-less constructor for the TestCase class. But I'm
> +1 to require JUnit 3.8+ in Cactus 1.6.


---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org

RE: Serializing test case classes

[Vincent Massol <vm...@pivolis.com>]

> -----Original Message-----
> From: Nicholas Lesiecki [mailto:ndlesiecki@yahoo.com]
> Sent: 02 November 2003 17:14
> To: Cactus Developers List
> Subject: Re: Serializing test case classes
> 
> (Sorry I'm late in jumping onto this thread)
> 
> This seems like a good idea because it will finally eliminate the
> counterintuitive behavior of the test state not persisting from the
client
> to the server. However, will the test be reserialized and sent back to
the
> client to be finished? It seems like the process should be
symmetrical...
> 

In JUnit, the test result is not hold in the test case instance. The
test result is already "serialized". We are serializing in XML and I'd
like to keep that feature as it's quite useful and allows to run cactus
tests from a browser (even applying a stylesheet on the client side).
Independently of this we could send back the test case instance to the
client but it becomes really complex to implement (it will require one
addition HTTP request).

> > It might be good to keep the
> > current behaviour as a fallback if the test case is not
serializable.
> 
> I'm -1 for having two modes. I doubt many users are taking advantage
of
> the
> non-Cactus suite method of running tests, and requiring them to make
the
> tests serializable seems like a small burden.

I'm not sure I agree. I think I'd prefer to find a solution to support
existing ServletTestSuite tests. One solution is to continue to support
the existing mechanism, possibly deprecate it if we think the new one is
better( but that's to be proved first).


-Vincent

[snip]


---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org