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
