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.197 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=EYgnB2Mpv8hx4lquKCL9a5deoow3hWiKT0Lc7PpjKbbrn5WWJfQtTH4dgM3XX/YpqhjbEzsRUd0f483ueScSof2P2oT+F6Md9HF4wbg2EHUxuYF4ErsKpIkzd9/7sVaQgI+NobAcCG5uD0B0YjQrB3HeXpDMHQIfxFElvAQsTJ4=
Message-ID: <906dd82e0601282241s4031f878wec202c06c657f2e5@mail.gmail.com>
Date: Sun, 29 Jan 2006 12:41:36 +0600
From: Mikhail Loenko <mloenko@gmail.com>
To: harmony-dev@incubator.apache.org, george.c.harley@googlemail.com
Subject: Re: [testing] code for exotic configurations
In-Reply-To: <906dd82e0601282022l43ac78cdud3f58eb485d73c82@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <43D9DF6C.5080508@gmail.com> <43DA1A8E.7020207@googlemail.com>
	 <906dd82e0601270533r35ae49b0j7161127cf3a8e551@mail.gmail.com>
	 <43DA2A6D.4070509@googlemail.com>
	 <906dd82e0601270633s4ac1d3a4v1d3e0c9d3ac3ba06@mail.gmail.com>
	 <46d21a9a0601270740p23a2f124hee03d0fdff7cdeae@mail.gmail.com>
	 <906dd82e0601280044o19c4c396y90f71e14a3fe36a6@mail.gmail.com>
	 <906dd82e0601280113p22a1bf6bi473ba377a0ef6663@mail.gmail.com>
	 <43DBBE9C.8090403@googlemail.com>
	 <906dd82e0601282022l43ac78cdud3f58eb485d73c82@mail.gmail.com>

P.S. There are also 'integration' tests that verify how different 'units'
work together.

I think the areas of various tests intersect and it would be good to define
them on this early stage

Thanks,
Mikhail

On 1/29/06, Mikhail Loenko <mloenko@gmail.com> wrote:
> Hi George,
>
> another example: implementation of SecureRandom might depend on
> file:/dev/random
>
> So, depending on OS, the bytes produced by my implementation of
> SecureRandom might be not too random or too secure.
>
> How do you consider  the test that verifies behavior of *my* code
> that depends on OS? Is it unit or system?
>
> Thanks,
> Mikhail
>
> On 1/29/06, George Harley <george.c.harley@googlemail.com> wrote:
> > Hi Mikhail,
> >
> > Comments inlined below.
> >
> > Best regards,
> > George
> > IBM UK
> >
> >
> > Mikhail Loenko wrote:
> > > Hi Anton,
> > >
> > > On 1/28/06, Mikhail Loenko <mloenko@gmail.com> wrote:
> > >
> > >> On 1/27/06, Anton Avtamonov <anton.avtamonov@gmail.com> wrote:
> > >>
> > >>> Sorry for being away during the major part of your discussion. Hope
> > >>> I'm still not too late.
> > >>>
> > >>> As I can see currently we have only one 'exotic' situation - some
> > >>> tests which are based on providers and use so many provider's
> > >>> fucntionality that cannot be replaced with mock objects in a
> > >>> reasonable time.
> > >>>
> > >
> > > You have only one example, not one situation - there is a difference.=
.. <g>
> > >
> >
> > Would you like to give us some more examples ?
> >
> > > Harmony has a modular structure and final product may be assembled fr=
om
> > > the modules we can not even think of yet. And the only thing we know =
about
> > > those modules is that they follow the spec.
> > >
> > > You likely know, security module that does not have any provider or a=
ny
> > > algorithm implementation follows the spec :). How do you think, will
> > > java.util or java.crypto work without those implementations? No.
> > >
> > > So, following your logic, all unit tests should either do not rely on
> > > other modules
> > > or include their own implementation of those modules (and better - fu=
ll J2SE
> > > implementation :).
> >
> > That was not my interpretation of what Anton wrote. What do you conside=
r
> > is actually being tested by a unit test ? Is it *just your code* or is
> > it *your code plus the system around it* ? I am really keen to hear you=
r
> > answer as I think it lies at the very heart of this discussion.
> >
> >
> > >  Tests that do not include their own J2SE are system ones,
> > > as they rely on environment.
> > >
> >
> > Could you elaborate a bit more on this point please ?
> >
> > > What I think is we have to be ready that some functionality would be =
unusable
> > > or untestable in some situations and our tests/framework would better
> > > be ready for it.
> > >
> >
> > That is a system test issue not a unit test issue.
> >
> > > Thanks,
> > > Mikhail
> > >
> > >
> >
> >
>