Friday, January 30, 2009

A tip for TestNG: Keep the Constructor Simple

TestNG does not do a great job of reporting exceptions when instantiating your test classes. Keep the content simple. If you are going to do anything that can throw an exception, defer it by creating a setup method annotated with @BeforeClass.

In my situation, I had an exception, and add my normal TestNG verbosity level, 2, there was no obvious output explaining why my tests didn't run, just a message about "unable to instantiate" my test case class. Upping the verbosity to 10 helped me identify the problem ... at which point I moved a bunch of setup logic out of my constructor and into a setup configuration method.

1 comment:

  1. In general, I find it extremely dangerous, putting setup logic in constructors. The semantics of it all are very fraught. I tend to use my constructors only to assign to final variables, and do any set up in a separately managed lifecycle, or on-demand later in the life of the component (though I prefer the former so I can validate everything before marshalling the component)

    One way or another, I think that keeping the Constructor simple is a good piece of advice, period, not just for TestNG or Unit Testing in general.

    ReplyDelete

Please note that this is not a support forum for Tapestry. Requests for help will be deleted. Please subscribe to the Tapestry user mailing list if you are in need of support, or contact me directly for professional (for pay) support.

Spammers: Don't bother. I delete your comments and it's a waste of time for both of us. 垃圾邮件发送者:不要打扰。我删除您的评论和它的时间对我们双方的浪费