harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Harley <george.c.har...@googlemail.com>
Subject Re: Unit testing revisited
Date Thu, 23 Mar 2006 21:27:25 GMT
Stepan Mishura wrote:
> On 3/22/06, Leo Simons  wrote:
> <SNIP>
>
>
>   
>> In any case, the obvious answer to the question is that you can do it by
>> writing your implementation so that it is implementation testable in that
>> manner. This means not (or allmost not) using package-private access
>> definitions anywhere. If "protected" can make sense, you get to do things
>> such as
>>
>> public class MyTestCase extends TestCase
>> {
>> public static class MyExtended extends My
>> {
>>     public My m;
>>
>>     public MyExtended( My m )
>>     {
>>       this.m = m;
>>     }
>>
>>     public Object exposedFoo()
>>     {
>>       return m.foo();
>>     }
>> }
>> }
>>     
>
>
> Just under impression of studying TestNG :-)
>
> @Test
> public class MyTest extends My {
>
>     @Test
>     public void testFoo(){
>         // tests exposed foo()
>     }
> }
>
>   

Hi Stepan,

Sorry if this has already been pointed out but I think this is pretty 
much the approach adopted by JUnit 4 as well. There is no longer any 
need for test classes to extend TestCase nor is their any need for the 
testing class to be annotated : just the test methods will suffice.

> If "protected" does not make sense, you can put the "real" implementation
>   
>> in some other package, and then the package-private stuff is nothing more
>> than a facade for that real implementation (you still can't
>> implementation-test the facade. What you can do is to use code generation
>> to create the facade, and then implementation test the code generation.
>> Or just not bother). Eg
>>
>> --
>> package java.foo;
>>
>> import o.a.h.j.foo.FooImpl;
>>
>> class Foo { /* package private */
>> private final FooImpl f = new FooImpl();
>>
>> void foo()
>> {
>>    f.foo();
>> }
>> }
>> --
>> package o.a.h.j.foo;
>>
>> public class FooImpl
>> {
>> public void foo()  // readily testable, cuz public
>> {
>>    /* ... */
>> }
>> }
>> --
>>     
>
>
> Hmm, testing defines how to implement package access functionality. IMHO, it
> is not correct approach.
>
> The last option I'm aware of is to resort to using reflection,
>   
>> since the runtime type system can bypass any and all access restrictions
>> if you have the appropriate security manager, but that leads to rather
>> painful test coding and makes the test coding error prone.
>>     
>
>
> It seems to me that we have to develop a 'harmony testing framework' to
> satisfy all our needs.
>
> Thanks,
> Stepan.
>
> There is also the possibility that all the package-private materials in
>   
>> reality are fully exercised if you test the public parts of the package
>> thoroughly enough. A coverage utility like clover can show that. XP
>> (extreme programming) purists (like me) might argue that if you have
>> package-private stuff that is not exerciseable through the public API
>> that the package-private stuff needs to be factored out. But lets try not
>> to argue too much :-)
>>     

I don't want an argument any more than the next person but ... I 
completely agree with the above statement. If you can't test code by 
going through the public API then how will the users ever get to 
exercise it in the "real world" ?

Best regards,
George


>>     
>>>>> Given that this
>>>>> o.a.h.t.* pattern comes from Eclipse-land, how do they do it?
>>>>>           
>> I doubt it comes from Eclipse-land. If ViewCVS wasn't locked for CVS
>> I could probably find you code from 1997 at the ASF that has a .test.
>> package in the middle.
>>
>>     
>>>>> I
>>>>> couldn't imagine that the Eclipse tests don't test package protected
>>>>> things.
>>>>>           
>>>> The only thing shared with Eclipse-land here is the *.tests.* package
>>>> name element, hardly significant or unique I expect.
>>>>         
>>> Well, it is around here. While I haven't done a survey, I'm used to
>>> projects keeping things in parallel trees to make it easy to test.
>>>       
>> If with "here" you mean "the ASF" I'm happy to challenge the assertion :-)
>>
>>     
>>> Granted, projects don't have the problem we have.
>>>
>>> The thing I'm asking for is this - how in Eclipse-land do they test
>>> package protected stuff?  How do they do implementation tests?
>>>       
>> I suspects its one or more of the above. For my own code, I tend to
>> design it so that implementation tests are not neccessary - eg I build
>> a large amount of specification tests (API tests) and verify that the
>> code coverage from running the API tests is 100%. Of course we don't
>> have that luxury (the API is already defined, and most of it probably
>> wasn't designed with this whole "purist" testing thing in mind).
>>
>>     
>>>> Eclipse testing does not have the java.* namespace issues with
>>>> classloaders that we have got.
>>>>         
>>> Right, but that's a classloader and security manager issue for the
>>> testing framework, isn't it?
>>>
>>> Hypothetically....suppose we decided (for whatever reason) that we
>>> weren't going to test in situ to get better control of the environment.
>>>  What would you do?
>>>       
>> What does "in situ" mean?
>>
>>     
>>>>> I've been short of Round Tuits lately, but I still would like to
>>>>> investigate a test harness that helps us by mitigating the security
>>>>> issues...
>>>>>           
>>>> Today we run all our tests in one suite on the classpath.  They are API
>>>> tests.
>>>>         
>>> I hope they are more than API tests.
>>>       
>> See above for why one could hope they don't need to more than API tests (I
>> doubt it, but in terms of what would be *nice*...)
>>
>>     
>>>> I expect that we will at least have another test suite of
>>>>         
>> implementation
>>     
>>>> tests.
>>>>
>>>> However, over the last few weeks we have been discussing the other
>>>> 'dimensions' of testing that we want to embody, and we haven't settled
>>>> on a suitable way of representing those different
>>>>         
>> dimensions.  Filenames
>>     
>>>> for testcases may do it if we can squeeze in enough information into a
>>>> filename (I don't like that approach, BTW)
>>>>         
>>> I don't either.
>>>
>>> , or explicitly defining
>>>       
>>>> different suites of tests.
>>>>         
>>> Which makes sense.
>>>       
>> Yup. It could even make sense to build some rather large extensions to
>> JUnit
>> to make all this stuff more manageable (eg we *can* do stuff like
>>
>> MyApiTest extends AbstractHarmonyTestCase
>> {
>> static { markTestStyle(API); }
>>
>> /* ... */
>> }
>>
>> MyApiTest extends AbstractHarmonyTestCase
>> {
>> static { markTestStyle(IMPL); }
>>
>> /* ... */
>> }
>>
>> , or similar things using 1.5 annotations).
>>
>>
>> cheers!
>>
>>
>> Leo
>>
>>     
>
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>   


Mime
View raw message