harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <ndbe...@apache.org>
Subject Re: [classlib][test] Migration to testNG?
Date Sat, 07 Jun 2008 01:44:18 GMT
Again, I'll mention that it was a long time ago -- Jul 2006; two years ago.
There has been two years of work on building tests and TestNG wasn't that
compelling then and still isn't that compelling now. I've read many articles
and blog posts like the one you mentioned, but I've yet to actually seen any
project actually using TestNG. I certainly don't survey all open source
projects, but of the dozen or so that I actively observe they all use JUnit.

We're invested in JUnit and it seems the most pragmatic to just upgrade. In
fact, I think I'll try that; there shouldn't be anything holding us back
from upgrading the library and letting people try it out.

As for Hamcrest, yes it is an independent library, but JUnit 4.4 includes
direct support for it in the org.junit.Assert.assertThat and assumeThat
methods.

-Nathan

On Fri, Jun 6, 2008 at 1:04 AM, Sean Qiu <sean.xx.qiu@gmail.com> wrote:

> We already have a impassioned debate for these two cadidate[1].
> IMHO, TestNG is more rounded and powful.
> It seems that TestNG has more features that Junit don't[2].
>
> For Hamcrest assert, it is interesting and should valueable to us.
> I think there is no doubt that we could include them with TestNG.
> It should be a independent library. (Corrent me if i was wrong)
>
> [1] http://markmail.org/message/w25yywlbjeicvhhe
> [2]
> http://lijinjoseji.wordpress.com/2008/02/29/testng-56-and-junit-44-which-framework-you-will-choose-for-unit-testing/
>
> 2008/6/6 Nathan Beyer <ndbeyer@apache.org>:
> > That discussion was a very long time ago. Is there still value in TestNG?
> > I'd prefer to move to JUnit 4.4. All of our current tests will continue
> to
> > work and new tests can be implemented using the latest conventions and
> older
> > tests can be updated as we get to them. JUnit 4.4 is a far cry from 4.0.
> >
> > Here's the things I think would be create for our use and testing in
> general
> > - Matchers and the 'assertThat' - much more readable code and readable
> > failure messages
> > - Assumptions and the 'assumeThat' - allows methods to add statements
> that
> > guarantee that preconditions for the test are correct; this allows tests
> to
> > fail such that you know it's an environment issue and not an actual test
> > failure
> >
> > If you're not familiar with matchers, check out this quick tutorial -
> > http://code.google.com/p/hamcrest/wiki/Tutorial.
> >
> > -Nathan
> >
> >
> > On Thu, Jun 5, 2008 at 10:21 PM, Sean Qiu <sean.xx.qiu@gmail.com> wrote:
> >
> >> Hi, all.
> >>
> >> We had discussed the migration to testNG before and got some conclusions
> >> for
> >> grouping[1]
> >> including how to deal with boot path test[2]. Am i missing something?
> >> Is it still in our schedule? I think it's valueable to Harmony.
> >> I volunteer to carry out this job if no one objects.  Any other
> volunteers?
> >>
> >> IMHO, we can only add some ant tasks to integrate testng at the
> beginning.
> >> So our original junit tests can still work at the mean time when
> migrating.
> >> When one module's migration task is finished, we can judge the result
> >> to dertermine whether we should go on for other modules.
> >>
> >> Maybe we can create a branch for luni to start this work, shall we?
> >> therefore there won't be any impact on other's development.
> >> Once it is completed in the branch, we could merge it back to our trunk.
> >> Does it make sense?
> >>
> >> Any sugestions or comments are welcomed. Thanks very much.
> >>
> >> [1] http://wiki.apache.org/harmony/Testing_Convention
> >> [2]
> >>
> http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg12413.html
> >> [3] http://testng.org/doc/documentation-main.html#annotations
> >>  --
> >> Best Regards
> >> Sean, Xiao Xia Qiu
> >>  China Software Development Lab, IBM
> >>
> >
>
>
>
> --
> Best Regards
> Sean, Xiao Xia Qiu
>
> China Software Development Lab, IBM
>

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