Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mloenko@gmail.com designates
 66.249.92.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=M5LiZs+AMQ9N7IRannqMMExD7fOSRROggyDBd0G0Cnn7P+s19h6Iaa64zu45CzdBQ7+Cnsc0r4HiNX3oAaAxtYTQ+xlImyRshzV2ZcBZi2X/cc6R5u/e6gNDWzs3l7HEEmf6oPl8pzLI4Y50mMeVgt6qdLRU7757Cg3pPjn/PJM=
Message-ID: <906dd82e0605252234s132f770bj22d795d2ac7d62bd@mail.gmail.com>
Date: Fri, 26 May 2006 12:34:45 +0700
From: "Mikhail Loenko" <mloenko@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Layout of tests in crypto module
In-Reply-To: <447691D6.1080901@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <906dd82e0605142112k3bce88a2i9842b6375c03f734@mail.gmail.com>
	 <906dd82e0605180320g13443b58l88669dc503d76941@mail.gmail.com>
	 <446C5841.6090707@googlemail.com> <44735ACC.6020702@pobox.com>
	 <906dd82e0605232130k5c6db8b1v7259bb9bcc61c183@mail.gmail.com>
	 <447555F5.4010103@pobox.com>
	 <906dd82e0605250102o5f70db48naa8149ffd85f91f2@mail.gmail.com>
	 <4475BC6A.7000403@gmail.com>
	 <906dd82e0605252029w48ad796cy9104c2e87b2df372@mail.gmail.com>
	 <447691D6.1080901@gmail.com>

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-independen=
t
things over it.

I think having tests impl-independent is more preferable goal than not havi=
ng
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 th=
e
> >> > 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 th=
at
> >> >> 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.or=
g
> >> >> 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.o=
rg
> >> >
> >> >
> >>
> >> --
> >> 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