New annotations are in!

[Cédric Beust ♔]

I just finished implementing the new annotations.  The code is checked in, all the examples have been ported to the new notation and they all pass. I preserved the older tests in a v4/ directory, so a full build of TestNG now tests the following:

• JavaDoc annotations with JDK1.4
• Annotations with JDK 5
• JavaDoc annotations with JDK 5
• v4 JavaDoc annotations with JDK1.4
• v4 Annotations with JDK 5
• v4 JavaDoc annotations with JDK 5

That's a lot of testing...

Here is what the new hotness looks like:

@BeforeSuite, @AfterSuite, @BeforeTest, @AfterTest, @BeforeGroups, @AfterGroups, @BeforeClass, @AfterClass, @BeforeMethod, @AfterMethod

@testng.before-suite, after-suite, before-test, after-test, before-groups, after-groups, before-class, after-class, before-method, after-method

I hesitated for a while between @BeforeMethod and @Before (like JUnit 4 does), and I opted for the former because @Before is too vague in my opinion. If you think we should try to be more compatible with JUnit4, let me know and we can always change it.

Implementation-wise, I cheated somewhat and instead of introducing a new facade for each of the new annotations (e.g. IBeforeSuite), I actually re-used the existing IConfiguration and I set the right boolean on it.  The benefit:  I only had to change the front-end of the parser and all the rest of the code worked pretty much right out of the box.

Try it and let me know what you think!

--
Cédric

[Eran]

On 6/23/06, Cédric Beust ♔ <cbe...@google.com > wrote:

I just finished implementing the new annotations.  The code is checked in, all the examples have been ported to the new notation and they all pass. I preserved the older tests in a v4/ directory, so a full build of TestNG now tests the following:

• JavaDoc annotations with JDK1.4
• Annotations with JDK 5
• JavaDoc annotations with JDK 5
• v4 JavaDoc annotations with JDK1.4
• v4 Annotations with JDK 5
• v4 JavaDoc annotations with JDK 5

That's a lot of testing...

Here is what the new hotness looks like:

@BeforeSuite, @AfterSuite, @BeforeTest, @AfterTest, @BeforeGroups, @AfterGroups, @BeforeClass, @AfterClass, @BeforeMethod, @AfterMethod

@testng.before-suite, after-suite, before-test, after-test, before-groups, after-groups, before-class, after-class, before-method, after-method

I hesitated for a while between @BeforeMethod and @Before (like JUnit 4 does), and I opted for the former because @Before is too vague in my opinion.

I also prefer @BeforeMethod as it's more consistent with the rest of the annotations.

If you think we should try to be more compatible with JUnit4, let me know and we can always change it.

I don't think we should even consider JUnit. TestNG is a great framework which stands on its own and I see no reason to maintain compatibilty with another framework which is light years behind it.

[Alexandru Popescu]

Great! I will check it in a couple of hours.

./alex
--
.w( the_mindstorm )p.

On 6/23/06, Cédric Beust ♔ <cbe...@google.com> wrote:

[Andreas Guther]

Hi Eran,

Looking at and comparing with JUnit is per se no a bad thing. I agree
with you, that TestNg is a great testing framework, and I also agree
that @BeforeMethod is more expressiv than just @Before.

All I want to say is that JUnit is the de-facto standard and many,
many projects are out there which use JUnit. People starting with
TestNG will most likely come from JUnit and why not making the
transition as smooth as possible. And then there are situations where
both frameworks are used in paralell, like in the company I am working
with. I often switch between JUnit and TestNG tests.

The beauty of JUnit I think lies in its simplicity. TestNG is more
like a Swiss knife, very powerfull and ready for many different
situations. But sometimes it is a little bit difficult to get out the
right one. For a Swiss knife you need good and strong fingernails,
for TestNG with so many configurations options you need a great
memory.

Don't be too hard on JUnit.

Andreas

On 6/23/06, Eran <era...@gmail.com> wrote:
> On 6/23/06, Cédric Beust ♔ <cbe...@google.com > wrote:
> > I hesitated for a while between @BeforeMethod and @Before (like JUnit 4
> does), and I opted for the former because @Before is too vague in my
> opinion.
>

[Alexandru Popescu]

#: Andreas Guther changed the world a bit at a time by saying (astral date: 6/26/2006 2:31 AM) :#

> Hi Eran,
>
> Looking at and comparing with JUnit is per se no a bad thing. I agree
> with you, that TestNg is a great testing framework, and I also agree
> that @BeforeMethod is more expressiv than just @Before.
>
> All I want to say is that JUnit is the de-facto standard and many,
> many projects are out there which use JUnit. People starting with
> TestNG will most likely come from JUnit and why not making the
> transition as smooth as possible.

... and imo this is a good reason to have TestNG special annotations. You will be able to use both
without having to use fqn-s ;-).

./alex
--
.w( the_mindstorm )p.

And then there are situations where

[Jesse Kuhnert]

Wasn't testng the de-facto standard for writing annotation driven tests...How did junit get insta-cred in this area? ;)

--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around dojo/tapestry/tacos/hivemind.

[Andreas Guther]

I was thinking in a more general way, not JUnit 3.8 vs. JUnit 4.0.
True, TestNG was there first. My feeling is, that most test folks
will move to annotiations now that JUnit has it and only once
companies start to move to Java 5. Java 6 is ante portas and from
what I can see most companies are still only *thinking* about moving
to Java 5 (mine included).

Andreas

[Mark Derricutt]

Actually, I believe NUnit was there first to use annotations under the .NET platform.  There's also JTiger but I'm not sure if that was out before or after TestNG?

[Eran]

Hi Andreas,

Sorry if I sounded too harsh but I can sum up my experience with JUnit in one word: frustration.
Mandatory inheritance, the super() anti-pattern, the statics used in attempt to maintain state between tests, the inability to easily select test configurations (which is a must in the multi-platform environment that I'm in) - all these and other reasons left a very bad impression on me.

It's true that TestNG has many features but for a newcomer who needs only basic testing it's just as simple as JUnit (just substitute setUp() for @BeforeMethod, testXXX() for @Test, etc). The extra features can be used if and when needed (in my opinion, it's better to have features you don't need than miss a feature you do need).

What I meant to say in my previous post is that decisions made regarding TestNG should not take JUnit into account and the compatibility with it is needed only for the JUnit2TestNG converter.

Regards,
Eran

On 6/26/06, Andreas Guther <andreas...@gmail.com > wrote:

[Hani Suleiman]

On Jun 26, 2006, at 2:08 PM, Eran wrote:
>
>
> What I meant to say in my previous post is that decisions made
> regarding TestNG should not take JUnit into account and the
> compatibility with it is needed only for the JUnit2TestNG converter.

I agree.

I don't understand the argument for choosing similar annotations as
JUnit, beyond the psychological one. It'd be like choosing to have a
TestCase class, because that's what JUnit does. It still wouldn't
work as expected (it'd be in another package, so you can't be
framework independent), and all it does is cause confusion (oh, I
have both in my classpath, and I accidentally imported the wrong
one). Besides, as Cedric i think pointed, in typical JUnit fashion,
@Before is too simplistic and assuming. The JUnit people don't seem
to have quite figured out what others who use annotations regularly
already have, namely that they need to be more descriptive than
regular classes, since you hardly ever seen the package in the
annotation.

Of course, if one were to apply that same rule to tng's annotations,
we'd be forced to admit that @Configuration is an equally bad name,
and should have instead been @TestConfiguration ;)

[Mark Derricutt]

On 6/27/06, Hani Suleiman <ha...@formicary.net> wrote:

JUnit, beyond the psychological one. It'd be like choosing to have a
TestCase class, because that's what JUnit does. It still wouldn't
work as expected (it'd be in another package, so you can't be
framework independent), and all it does is cause confusion (oh, I

Do I spot a call for commons-testing here Hani? ;-)  *runs in fear of life and bile*

Mark