February 07, 2006

Announcing TestNG 4.5

I'm happy to announce the immediate availability of TestNG 4.5.  It features a lot of bug fixes, a few new minor features (runAfter didn't make it in this release but will appear in the next one).  And of course, a new look for the Eclipse plug-in (the update site has been updated as well), a new look for the documentation and a few added sections as well.

[Interestingly, this is my 350th entry on this weblog, not counting the two years I spent on JRoller before that]

Here is the change log.

4.5

Core:

  • Fixed: Methods were not implicitly included, only groups
  • Fixed: Bug with failed parent @Configuration don't skip child @Configuration/@Test invocations
  • Fixed: Bug with overridding @Configuration methods (both parent and child were run)
  • Fixed: Bug when overriding beforeClass methods in base class (cyclic graph)
  • Added: Support for JAAS (see org.testng.IHookable)
  • Fixed: Problem with nested classes inside <package name="foo.*"
  • Fixed: If a group is not found, mark the method as a skip instead of aborting
  • Fixed: testng-failed.xml was not respecting dependencies
  • Fixed: class/include method in testng.xml didn't work on default package
  • Fixed: DTD only allowed one <define>
  • Fixed: ArrayIndexOutOfBoundsException for jMock
  • Added: dependsOnMethods can contain methods from another class
  • Fixed: JUnitConverter required -restore, not any more (option is now a no-op)
  • Fixed: JUnit mode wasn't invoking setName() on test classes
  • Added: Regular expressions for classes in <package>
  • Added: Distributed TestNG
  • Fixed: Command line parameters and testng.xml are now cumulative
  • Fixed: Reports now work for multiple suites
  • Fixed: Was ignoring abstract classes even if they have non-abstract instances
  • Fixed: If setUp() failed, methods were not skipped
  • Fixed: Was not clearly indicating when beforeSuite fails
  • Added: @Configuration.inheritGroups
  • Fixed: inconsistency between testng.xml and objects regarding method selectors

Eclipse plug-in:

  • New look for the progress view.
     
Posted by cedric at February 7, 2006 11:08 PM
Comments

Hi Cedric.

Could you please elaborate on "Added: Distributed TestNG" feature. It looks really interesting. Do you have any info about it, like links, examples, blog entries?

Thanks!!
--Vladimir

Posted by: VVS at February 8, 2006 12:31 PM

Hi Vladimir,

I just posted a new entry explaining what Distributed TestNG is...

Feedback welcome!

Posted by: Cedric at February 8, 2006 12:55 PM

TestNG IDEA Plug-in has problem with IntelliJ IDEA Demetra build 5131. But maybe too early to work for Demetra's plugin. ;-)

Posted by: t800t8 at February 9, 2006 06:00 AM

TestNG IDEA Plug-in has problem with IntelliJ IDEA Demetra build 5131. But maybe too early to work for Demetra's plugin. ;-)

Posted by: t800t8 at February 9, 2006 06:01 AM

Help, I'm trying to find a senior dev with exp developing eclipse plugins and familiarity with AJAX. Also, some one who is active in the community and would like to be a guru at an excellent startup in gorgeous San Diego. Please contact me if you know someone or would like to see the job description out of curiosity. ;-)

Posted by: Sunny at April 28, 2006 03:13 PM

Needed to decorate test cases (acquire/release resources around test cases, get hold of the current test name.) Just found IHookable - w00t!

It would be nice if test decoration were a first class entity in TestNG. (We can fake it with @BeforeMethod/AfterMethod if the execution can be broken up into separate methods. For a single execution context, e.g. as needed with JAAS, the alternative, IHookable, runs for all tests on that test class.)

A TestDecorator would generalize IHookable and allow it to be tied in with groups, so the decorators are only applied to certain tests, or allows multiple decorators to be applied.

@TestDecorator(groups="...")
ITestDecorator createDecorator()
{
return new ITestDecorator() {
public void runTest(Runnable test) {
// pre-execute stuff
test.run();
// post-execute stuff
}
}
}

(If you prefer not to introduce a code dependency in clients on a TestNG interface, perhaps java.util.concurrent.Executor might fit instead of ITestDecorator.)

Clients that want the current ITestResult can cast the Runnable argument to an appropriate interface, either ITestResult itself, or an interface that provides the ITestResult.

Behind the scenes, TestNG would instantiate Runnable implementations that handle chaining of multiple test decorators for a given test method.

Posted by: Matthew McGowan at August 15, 2006 12:41 PM
Post a comment






Remember personal info?