Re: inner static classes

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

Andrei,

I am not religious on this point. I guess your way is fine. I can certainly
understand your concern for having the code and test code in the same place
+ addressing the testing of private methods.

Let's try to find some disadvantages (in no specific order, thus as it comes
to my mind) :
- inner classes are less well supported by IDEs (a lot have bugs)
- when you right click on your class in the IDE, and you click on execute,
is it going to execute the main from TestCase or the main from
ServletTestCase, or are the IDEs intelligent enough to ask you ? :)
- there might be a slight security hole in some cases if you leave the test
classes with your production code. Malicious users could try to call the
test class which, if it ontains errors, might set some state in memory which
would affect the behaviour of the class under test when accessed [that would
be true if your class under test has some static variables for example or
calling anything static]. ? So, it is difficult to package only the runtime
code without the test code.
- The class under test become bigger and more difficult to read.
- How I normally do it, is to have 2 directories, like one named "main" (or
core) and another named "tests" for example. Under each of these I would
have the same package hierarchy [which will let me unit test my protected
methods]. Also, with some ides, you have the option of seeing the sources
from different directories merged together in a single view and you'll be
able to see your XXXTest.java and XXX.java classes next to each other. Thus,
it is easy to find the test class related to any class.
- With Cactus, your test class is instanciated both on the client side and
on the server side. Thus, your class under test will also need to be
instanciated on the client side, complexifying a bit more all the jars that
you need to have on the client side classpath.

comments ? :)

-Vincent

----- Original Message -----
From: "Andrei" <av...@mail.ru>
To: <ca...@jakarta.apache.org>
Sent: Monday, October 29, 2001 1:12 PM
Subject: inner static classes


> Hi all,
> I have got a question concerning inner static classes.
> I have just started using two static inner test classes for one java
class.
> It looks like this:
>
> public class MyClass {
>     ...
>
>     /** Test class.*/
>     public static class LocalTest extends junit.framework.TestCase {
>           // tests
>     }
>     /** Test class.*/
>     public static class ServerTest extends ServletTestCase  {
>           // tests
>     }
> }
>
> I test code that do not need to be executed on the server in
> the LocalTest class (usually small private methods).
> Advantages:
> 1. you do not think about the server while developing
> 2. test takes less time if executed alone.
>   (if you execute the whole suite for all classes you win nearly nothing)
>
> After developing it is possible to move all methods from LocalTest to
ServerTest and remove LocalTest. Or one can leave it as it is.
>
> The question is: is this way (using two inner test classes) error prone?
What are disadvantages?
>
> Many thanks,
>
> Andrei
>
> P.S. I could not find in the archive any messages about inner static test
> classes. Does anybody use them?
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re[2]: inner static classes

[Andrei <av...@mail.ru>]

Hello Vincent,
Thank you for your time.
I am also not religious on this point. As far as I can see this looks
like a code convention - you must have a code convention but the
bracket style is up to you :)

About test classes:
when you have compiled test classes you can do everything with them.
Ant is smart enough to meet your needs. I do not include test classes
in the production code.
About test sources:
Why people think that support of inner classes is more difficult then
support of independent files?

Anyway I tried inner test classes and separate test files both and found
the first way more comfortable. Is there anybody who tried inner tests
classes and refused them in favor of separate test files? Why?

I do not want to force everybody to use inner test classes. But it
seems to be a rather smart technology. But a little bit tricky at the
first impression.

VM> Andrei,

VM> I am not religious on this point. I guess your way is fine. I can certainly
VM> understand your concern for having the code and test code in the same place
VM> + addressing the testing of private methods.

VM> Let's try to find some disadvantages (in no specific order, thus as it comes
VM> to my mind) :
VM> - inner classes are less well supported by IDEs (a lot have bugs)
VM> - when you right click on your class in the IDE, and you click on execute,
VM> is it going to execute the main from TestCase or the main from
VM> ServletTestCase, or are the IDEs intelligent enough to ask you ? :)
VM> - there might be a slight security hole in some cases if you leave the test
VM> classes with your production code. Malicious users could try to call the
VM> test class which, if it ontains errors, might set some state in memory which
VM> would affect the behaviour of the class under test when accessed [that would
VM> be true if your class under test has some static variables for example or
VM> calling anything static]. ? So, it is difficult to package only the runtime
VM> code without the test code.
VM> - The class under test become bigger and more difficult to read.
VM> - How I normally do it, is to have 2 directories, like one named "main" (or
VM> core) and another named "tests" for example. Under each of these I would
VM> have the same package hierarchy [which will let me unit test my protected
VM> methods]. Also, with some ides, you have the option of seeing the sources
VM> from different directories merged together in a single view and you'll be
VM> able to see your XXXTest.java and XXX.java classes next to each other. Thus,
VM> it is easy to find the test class related to any class.
VM> - With Cactus, your test class is instanciated both on the client side and
VM> on the server side. Thus, your class under test will also need to be
VM> instanciated on the client side, complexifying a bit more all the jars that
VM> you need to have on the client side classpath.

VM> comments ? :)

VM> -Vincent

VM> ----- Original Message -----
VM> From: "Andrei" <av...@mail.ru>
VM> To: <ca...@jakarta.apache.org>
VM> Sent: Monday, October 29, 2001 1:12 PM
VM> Subject: inner static classes


>> Hi all,
>> I have got a question concerning inner static classes.
>> I have just started using two static inner test classes for one java
VM> class.
>> It looks like this:
>>
>> public class MyClass {
>>     ...
>>
>>     /** Test class.*/
>>     public static class LocalTest extends junit.framework.TestCase {
>>           // tests
>>     }
>>     /** Test class.*/
>>     public static class ServerTest extends ServletTestCase  {
>>           // tests
>>     }
>> }
>>
>> I test code that do not need to be executed on the server in
>> the LocalTest class (usually small private methods).
>> Advantages:
>> 1. you do not think about the server while developing
>> 2. test takes less time if executed alone.
>>   (if you execute the whole suite for all classes you win nearly nothing)
>>
>> After developing it is possible to move all methods from LocalTest to
VM> ServerTest and remove LocalTest. Or one can leave it as it is.
>>
>> The question is: is this way (using two inner test classes) error prone?
VM> What are disadvantages?
>>
>> Many thanks,
>>
>> Andrei
>>
>> P.S. I could not find in the archive any messages about inner static test
>> classes. Does anybody use them?
>>
>>
>> --
>> To unsubscribe, e-mail:
VM> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
VM> <ma...@jakarta.apache.org>
>>
>>


VM> --
VM> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
VM> For additional commands, e-mail: <ma...@jakarta.apache.org>




-- 
Best regards,
 Andrei                            mailto:avsomov@mail.ru


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>