harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [classlib] Layout of tests in crypto module
Date Fri, 26 May 2006 05:34:45 GMT
It is more preferable to have tests implementation-independent:
we can validate them on RI, the tests will not have to be modified if we
modify our implementation.

The test I was talking about was impl-independent. It obtained an instance of
an internal class by impl-independent way and then did some impl-independent
things over it.

I think having tests impl-independent is more preferable goal than not having
api tests in bootclasspath

Thanks,
Mikhail

2006/5/26, Richard Liang <richard.liangyx@gmail.com>:
>
>
> Mikhail Loenko wrote:
> > Hi Richard
> >
> > Do you mean a mock subclass of j.n.HttpURLConnection or a mock
> > subclass of
> > o.a.h.luni.internal....HttpURLConnection ?
> >
> > If it is a subclass for o.a.h... then it won't pass on RI - it would
> > be an impl test,
> Hi Mikhail,
>
> I'm sorry if my previous description made you confused. :-)
>
> AIUI, it IS an implementation test. Because we are testing Harmony's
> detail implementation.
>
> > if it is a subclass for j.n.HUC then it won't catch a problem in
> > o.a.h....HIC
> >
> > Thanks,
> > Mikhail
> >
> > 2006/5/25, Richard Liang <richard.liangyx@gmail.com>:
> >>
> >>
> >> Mikhail Loenko wrote:
> >> > Yes there is.
> >> >
> >> > They can access protected fields (they are also package-visible).
> >> Or they
> >> > can test something related to class loading.
> >> >
> >> > Example. Recently I committed
> >> >
> >> modules\luni\src\test\java.injected\java\net\HttpURLConnectionAccessor.java
> >>
> >> >
> >> > that is not a test though but something that is used by API test and
> >> > that must
> >> > be in bootclasspath. (I could refactor and put the test itself to the
> >> > bootclasspath)
> >> >
> >> Hello Mikhail,
> >>
> >> Instead of using HttpURLConnectionAccessor, we can access protected
> >> fields through a mock subclass of HttpURLConnection.
> >> > Thanks,
> >> > Mikhail
> >> >
> >> > 2006/5/25, Geir Magnusson Jr <geir@pobox.com>:
> >> >>
> >> >>
> >> >> Mikhail Loenko wrote:
> >> >> > 2006/5/24, Geir Magnusson Jr <geir@pobox.com>:
> >> >> >>
> >> >> >>
> >> >> >> George Harley wrote:
> >> >> >> > Hi Mikhail,
> >> >> >> >
> >> >> >> > That is a very good point and your suggestion of
> >> supplementing the
> >> >> >> class
> >> >> >> > or package name sounds like a very straightforward way
around
> >> the
> >> >> >> > problem. Because there will be a number of tests that
must be
> >> in an
> >> >> >> > identical package name to the type under test then it
seems that
> >> >> the
> >> >> >> > differentiating mark needs to be added to the test class
> >> name. Not
> >> >> >> > really sure what this could be. Given that we are all
settled on
> >> >> the
> >> >> >> > convention that a test type has the "Test" suffix, how
about
> >> >> just add
> >> >> >> > "Impl" to that suffix for implementation tests giving
us an
> >> >> "ImplTest"
> >> >> >> > suffix.
> >> >> >> > e.g.
> >> >> >> >
> >> >> >> > class under test : java.lang.SomeClassTest
> >> >> >> > implementation-independent test class :
> >> >> >> > o.a.h.module.tests.java.lang.SomeClassTest
> >> >> >> > Harmony-specific test class :
> >> >> >> > o.a.h.module.tests.java.lang.SomeClassImplTest
> >> >> >>
> >> >> >> Or
> >> >> >>
> >> >> >> o.a.h.<module>.apitest.java.lang.FooTest
> >> >> >> o.a.h.<module>.impltest.java.lang.FooTest
> >> >> >>
> >> >> >>
> >> >> >> Of course, the implementation test didn't need to be on the
> >> >> >> bootclasspath, it would simply be
> >> >> >>
> >> >> >> java.lang.FooTest
> >> >> >>
> >> >> >> with no other garbage in the package name
> >> >> >
> >> >> > Hi Geir
> >> >> >
> >> >> > how to distinguish between bootclasspath implementation test
> >> >> >   java.lang.FooTest
> >> >> > and bootclasspath api test
> >> >> >   java.lang.FooTest
> >> >>
> >> >> Is there such thing as an bootclasspath API test?
> >> >>
> >> >> geir
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> >> For additional commands, e-mail:
> >> harmony-dev-help@incubator.apache.org
> >> >>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >> >
> >> >
> >>
> >> --
> >> Richard Liang
> >> China Software Development Lab, IBM
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> --
> Richard Liang
> China Software Development Lab, IBM
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message