August 18, 2006Announcing TestNG 5.1: making testing easier, one thread at a timeTestNG 5.1 is now available for download from http://testng.org. The change log is included below and contains a lot of bug fixes, but also a particular feature I'd like to expand on. TestNG makes it very easy for you to run your tests in separate threads, which provides a very significant speed up in a lot of cases (this particular user said that switching to multithreaded tests reduced their test run times from forty minutes down to... four minutes!). However, when you do this, you can encounter various problems if the classes you are testing are not multithread-safe (which is very often the case). For example:
public class ATest {
private A a;
@BeforeClass
public void init() {
this.a = new A();
}
@Test
public void testf1() {
// test a.f1();
}
@Test
public void testf2() {
// test a.f2();
}
}
In this example, the two test methods testf1() and testf2() test the methods A#f1 and A#f2 respectively, but when you ask TestNG to run these tests in parallel mode, these two methods will be invoked from different threads, and if they don't properly synchronize with each other, you will most likely end up in a corrupt state. One way to solve this problem is to declare that the test methods depend on each other, thus forcing TestNG to run them in the same thread, but that's obviously tedious and also not semantically correct (they don't really depend on each other). Another possibility is to make A#f1 and A#f2 properly synchronized, but again, it's a lot of work just to enable testing, and while I'm fine with making minor modifications to my classes to make them easier to test (making certain methods more visible, adding accessors, etc...), I think that making my classes multithread-safe crosses the line. Therefore, TestNG 5.1 provides a new attribute in the @Test annotation, which can be specified at the class level:
When TestNG sees this flag, it will make sure that all the test methods in the given class are always run sequentially (right now, it uses the simplest way to achieve this goal: run all the test methods in the same thread, but there are other ways to do this). An interesting consequence of this fix (which was trivial to make since support for sequential runs this was already in TestNG because of dependencies) is that the workers used by TestNG can now contain either:
Obviously, the last two workers are going to be holding on to threads longer than the first one, but I still think that the runs will be faster than if the parallel flag is not set. Note that the link to the thread of discussion that I posted above (here it is again) is a good example of how new features are added to TestNG:
Here is the complete change log for TestNG 5.1 (big thanks to Alexandru for all the bug fixing!) Enjoy! Core
Eclipse plug-in
Improved behavior
Posted by cedric at August 18, 2006 09:38 AM Comments
I hope our users are happy with this new release and also for the new features added to the Eclipse plugin. ./alex I'm definitely very happy with the release AND eclipse plugin updates. Nice work guys! :) Posted by: Jesse Kuhnert at August 21, 2006 06:26 AMFor the eclipse plugin feature: Does this allow running a single test method with @Parameters with data from testng.xml file? If so how? I could not find the a option in the run configurations in Eclipse, nor in the mailing list on opensymphony. Thanks Posted by: Md at September 1, 2006 01:58 PMPost a comment
|