Perhaps we can get the benefits of the new approach without the problems. It is very important to me to be able to split my tests across multiple test case classes that share a single Selenium/Jetty setup. It takes too long to start up and shutdown Selenium/Jetty for each test case, and the one-big-test case is ultimately not scalable.
Can TestNG inject the configuration data (that current arrives via the constructor) directly into a @BeforeTest method? If so, then the base class for a TestCase can automatically start up Selenium/Jetty with correct configuration and track that in @AfterTest it should shut it down. The trick is coordinating multiple TestCases so that the *right* instance knows it is the one. End result: if you run on test method, or one test case, it will setup and shutdown selenium. If you run a suite, the first TestCase whose @BeforeTest method is invoked will remember, and shut it all down at @AfterTest. Actually, if the right information is stored into the ITestContext it doesn't matter which test suite shuts it all down. On Thu, Oct 14, 2010 at 10:54 AM, Igor Drobiazko <[email protected]> wrote: > I never liked the new approach to integration tests and would like to revive > the deprecated AbstractIntegrationTestSuite. > > The new approach doesn't allow me to run a single method inside a > integration test separately. I'm always forced to run the entire test suite > in Eclipse which is a big impact on my productivity. I've seen some comments > of other committers which makes me believe that I'm not the only one having > such a feeling. > > -- > Best regards, > > Igor Drobiazko > http://tapestry5.de > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
