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.
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)
ReplyDeleteOne 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.