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() } } 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 :-) > > > >>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