The TestNG team has announced the release of TestNG 2.5.

Highlights of this release:

• A brand new Web site
• An IDEA plug-in.
• An improved Maven plug-in.
• You can now specify entire packages in testng.xml instead of enumerating all your test classes.
• alwaysRun configuration methods: if a test fails, any configuration methods annotated with this boolean will always be run, regardless of whether something wrong happened during the tests.
• Package support in testng.xml.
• Bug fixes

Which unit testing framework are you using, and why?

'Brand new site' link missing: http://testng.org/doc/

Actually, I prefer to use JUnit, but I still uncertain about unit testing framework for projects based on JDK 5. If JUnit team is to delay their 4.0 version, TestNG would become my favorite.

Does the IDEA plugin need a specific IDEA version? I use IDEA 4.5.4 and the TestNG plugin still doesn't appear in the list of available plugins :-(

The plugin requires IDEA 5.0, and that your instance of IDEA is running under JDK5.0. The plugin does however support JDK 1.4 for tests.

The plugin requires IDEA 5.0, and that your instance of IDEA is running under JDK5.0. The plugin does however support JDK 1.4 for tests.

Then there's an IDEA 5.0 plugin not an IDEA plugin. I hope it's not too much effort mentioning the version number required on the website.

Next week I have to convince my boss buying the 5.0 upgrade:-)

The plugin requires IDEA 5.0, and that your instance of IDEA is running under JDK5.0. The plugin does however support JDK 1.4 for tests.

Then there's an IDEA 5.0 plugin not an IDEA plugin. I hope it's not too much effort mentioning the version number required on the website.

I was actually not aware of this limitation :-)

I updated the documentation, and you can be assured that the perpetrators will be appropriately reprimanded.

--
Cedric
http://testng.org

JUnit is still fine for everything I do with it, I don't really need a new test framework, even though I am doing all 1.5 development at this point. I did have a question about a statement the author made in one of his 'justification' posts on his blog. He says:

I don't have anything against static methods in general, I tend to use them as much as possible whenever they don't need access to any non-static fields since it decreases the coupling between my classes.

I'm not sure I understand this. How does calling Class.staticMethod() create less coupling than instance.nonstaticMethod()? And unless I'm just being dumb and the comment is justified, I admit to a little hesitation about adopting a framework developed by someone who doesn't understand what constitutes coupling in a design.

--james

JUnit is still fine for everything I do with it, I don't really need a new test framework, even though I am doing all 1.5 development at this point. I did have a question about a statement the author made in one of his 'justification' posts on his blog. He says:

I don't have anything against static methods in general, I tend to use them as much as possible whenever they don't need access to any non-static fields since it decreases the coupling between my classes.

I'm not sure I understand this. How does calling Class.staticMethod() create less coupling than instance.nonstaticMethod()? And unless I'm just being dumb and the comment is justified, I admit to a little hesitation about adopting a framework developed by someone who doesn't understand what constitutes coupling in a design.--james

If the method is non static, you need an instance to be able to run it, so you depend on the constructor(s) of this class and its state.

If the method is static, you need none of the above and it's also much easier to move this method around.

Now, how about actually judging TestNG on what it does instead of something you read years ago about me, mmmh?

--
Cedric
http://testng.org

Now, how about actually judging TestNG on what it does instead of something you read years ago about me, mmmh?-- Cedric

Snarky reply to snarky comment first -- actually I read it about 5 minutes before posting.

If the method is non static, you need an instance to be able to run it, so you depend on the constructor(s) of this class and its state.

1) You need either a pointer to the class or a pointer to the instance, but in either case you need a pointer, which is pretty much the base definition for "coupling" as far as I understand it.

2) Just because I have a pointer to an instance doesn't mean I constructed it and I am only depending on its state to the degree that I expect to modify it, which might be not at all (in the case of immutable model objects or stateless controllers, for instance).

3) In evaluating a product, especially an open source product, I find it useful to first verify if the people involved have solved the sort of problems I have, and if they have the same problem-solving approach. If I disagree with someone on the fundamental definition of the problem they're trying to solve, I'm not likely to be a great user for whatever it is they've built.

--james

If the method is non static, you need an instance to be able to run it, so you depend on the constructor(s) of this class and its state.

You've got to be kidding. If the method is non-static, you can refer to the instance through it's interface. Then you don't depend on the class, or its constructor.

If the method is static, then you always have a hard dependency on the class itself.

And unless I'm just being dumb and the comment is justified, I admit to a little hesitation about adopting a framework developed by someone who doesn't understand what constitutes coupling in a design.

Interesting, considering the JUnit folks plan on copying almost every feature of TestNG for JUnit 4. So, do you trust people who steal ideas from someone who supposedly doesn't understand what constitutes coupling in a design? Just curious.

Interesting, considering the JUnit folks plan on copying almost every feature of TestNG for JUnit 4. So, do you trust people who steal ideas from someone who supposedly doesn't understand what constitutes coupling in a design? Just curious.

It's not stealing. TestNG is open source, and so anyone can even "take" all the source code if they want to.

OTOH, it would be nice if JUnit 4 stopped being silly and just admitted that most of its roadmap comes straight from TestNG. I give JUnit its due (it is very successful, and has made a huge contribution), but you've also got to admit that it was totally stagnant until TestNG appeared on the scene and started picking up support.

As far as the conversation on statics, Cedric is of course wrong. But what can you expect from a guy who doesn't know how to indent his code? ;-)

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Cedric is of course wrong.

I think he is not wrong. When i want to make a method generic i just make it static and then i can indeed move it around real easy to a class where it belongs, dependencies are gone for a great part. I discovered this a short while ago and i find it therefore funny to read something about another guy taking the same approach. From an academic point of view this might not be the way but it works, period.

Coupling/decoupling from what ?

If my context is decoupling the invocation from the method's implementation
Class.staticMethod does definitely couple while
Interface.myMethod decouples. That's polymorphism. Nothing new to understand.

But if the context is referred to the component from within the method is invoked...
Class.staticMethod invocation does not couple (to the component!) as
Interface.myMethod does for the simple fact that I do not need to access any instance to invoke that method.
Now, rather than coupling/decoupling I would talk about dependencies (direct and indirect) but that's what I think (hopefully) Cedric meant.

Real example.
Thread.currentThread()

Now if you made it a member method (i.e. thread.getCurrentThread() ) you would need an
instance of Thread anywhere you want to use it
while with Thread.currentThread() you simply do not care. Just use it.

Having said that, I personally take the opposite approach of Cedric's, I try to avoid static as much as I can.

OOAD supposedly evolved to overcome limitations with Structured Systems AD (SSAD).

(some) Terms with OO: abstraction, encapsulation, inheritence, polymorphism.

(some) Terms with SS: coupling, cohesion.

(i am mot quite getting into the tools of the methodologies, just some terms).

during late 80s/early 90s when OO was beginning to become more popular/acceptable, it was assumed that people would thouroughly understand what is coupling and cohesion, and that would help solve design problems like
- does this method belong in this class?
- does this class belong to this package/namespace?
- ...

it seems with OO now being the default first thing that programmers know, understanding of coupling/cohesion has been lost.

a great book that extremely clearly defines degress of coupling & cohesion is "The Practical Guide to Structured Systems Design, Second Edition" by Meilir Page-Jones.

I think you failed to see my point...

... admitted that most of its roadmap comes straight from TestNG

And TestNG's innovation was to use annotations? I only read up on annotations during JavaOne in June... and the VERY first thing I thought of was using them to identify "test" methods, replacing JUnit's "begins with test" convention.

I didn't see anything else in that package which struck out in a new dimension from JUnit, so I'm just not sure TestNG has that much of a roadmap to steal from.

Now, if they had included some fancy type of automock which could instrument classes using cglib or something... but I'm sure someone else is doing something like that in another project that I'll read about in this space in the next few months.

And TestNG's innovation was to use annotations?

Not just that. In a nutshell:

- Groups (very important to define sets of test methods that cannot be adequately grouped by classes or packages, such as "long tests").
- Dependent methods
- Flexible runtime model (no need to recompile anything to invoke a different set of tests)
- Enable all kinds of testings, not just "unit"
- More granular configuration methods (before/after methods, classes, tests, entire suites)
- Parameters for test methods
- ... and much more

Please take a look at the documentation for more details: http://testng.org

Now, if they had included some fancy type of automock which could instrument classes using cglib or something... but I'm sure someone else is doing something like that in another project that I'll read about in this space in the next few months.

It's an interesting feature but probably as a plug-in, not in the core distribution.

Anyway, I'd be interested to discuss your ideas further if you'd like to expand on them and send me an email: we're always interested in expanding the scope of TestNG to whatever users need for their testing needs.

--
Cedric

When I install IntelliJ IDEA's TestNG plugin, it counteract JUnit plugin so I can not see green/red bar anymore, just text. Please ask me before you do that! ;-)