harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: [OT] Re: Unit testing revisited
Date Thu, 23 Mar 2006 09:16:27 GMT
On 3/22/06, Geir Magnusson Jr wrote:
>
>
>
> Leo Simons wrote:
> > On Wed, Mar 22, 2006 at 07:34:16AM -0500, Geir Magnusson Jr wrote:
> >>> LEO :
> >>> I'll point out that every time you restrict to an ordered sequence of
> >>> taking care of things in an open souce community you do slow them down
> just
> >>> a little (hey, that's an interesting assertion. Hmm. Should write a
> book
> >>> about it I guess) so make sure its what you want :-).
> >> Huh?
> >
> > You didn't say "let us test the code in isolation [using a smart
> framework]",
> > you said "let us test the code in isolation *first* [using a smart
> > framework]". I need to write a book about why I think the difference
> > matters, and it needs to be a book because I'll need many many words...
>
> Oh - no, I didn't mean that. Sorry. All three are independent.  You can
> do them in parallel.  We can build our mechanism to do the
> implementation tests correctly while we continue to do everything else.
>
> I just wanted to see if I could get through the fog and be clear what
> the issues are and stop confusing #1 and #2, both of which are important.
>
> To test java.util.Foo, I believe it's important to have BOTH
>
>     java.util.FooTest
>
> AND
>
>     org.apache.harmony.test.java.util.FooTest
>
> as they are intended to test different things (the first as a
> 'un-integrated' implementation test and the second as an 'in-situ'
> API/spec test).


Yes, indeed. We should admit that we need both tests rather then arguing
which test is the right.

Thanks,
Stepan.

If we agree on that and recognize that, I suspect the test debates will
> come to rapid closure, and we'll have a mini-roadmap of what we want to
> do in the testing area that is parallelizable and doesn't hold anyone up.
>
> geir
>
>
>


--
Thanks,
Stepan Mishura
Intel Middleware Products Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message