Adding multi test suite support to the Eclipse PDE unit automation process

I'm trying to adapt the pde unit test automation process from here [1] to handle multiple test suites. The article makes use of org.eclipse.jdt.internal.junit.model.ITestRunListener2 which is unable to handle multiple test suites. I'm thinking of using org.eclipse.jdt.junit.TestRunListener instead.

I tried to convert the included implementation of org.eclipse.jdt.internal.junit.model.ITestRunListener2 to implement junit.runner.TestRunListener since it's testRunStarted() method includes a test suite name parameter but was unable to find any example on how to adapt org.eclipse.jdt.internal.junit.model.RemoteTestRunnerClient into using it (I'm not sure even if the PDE test results protocol support it).

1. Will using JUnitCore.addTestRunListener(listener) be able to replace the whole test-results-listener approach ? there's no need to be able to run the tests remotely.
2. Any other suggestion on how to add multi suite support to [1] ?

[1] http://www.eclipse.org/articles/article.php?file=Article-PDEJUnitAntAutomation/index.html

Hello, this is the OP, couldn't add a commnet Paul Webster's reply, so I'm posting this.

The thing with RemoteTestRunnerClient is that it delegates notifications to it's listeners according to the protocol defined in org.eclipse.jdt.internal.junit.runner.MessageId, with messages being read from the TCP socket. The problem is that the TEST_RUN_START/END messages do not include the suite's name, causing all tests to be associated with the same suite.

I did take a look at the Eclipse Test Framework while setting up the automated test framework, but couldn't find any compelling reason to favor it over the approach suggested in the article. I'm not sure but I think the articles reason not to use the ETF was the lack of adequate support for test result aggregation. By now I can appreciate being able to specify which suites should run through test.xml files, as I am currently using the '-classnames' argume开发者_运维知识库nt passed to the 'org.eclipse.pde.junit.runtime.coretestapplication' application. I wouldn't mind considering a switch to the ETF but would like to have a compelling reason for it beforehand.

Bottom line is that with my setup doing 99% of what is required, I'd prefer a quick-&-dirty workaround as oppose to a full test system conversion.

I don't think you have to do anything w.r.t. RemoteTestRunnerClient. It takes a ITestRunListener2, which is implemented by TestSessionNotifier. That issues events to ITestSessionListener implemented by TestRunListenerAdapter, which forwards them on to TestRunListener

That being said, one of the pointers in that article was to the Eclipse Test Framework [1].

We use it to run our plugin tests. After getting the framework itself, each test plugin simply needs a test.xml [2] file. That file can specify UI tests and headless tests, and can list multiple TestSuites for that plugin. I've linked our example.

[1] http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.test/testframework.html?view=co

[2] http://dev.eclipse.org/viewcvs/viewvc.cgi/e4/org.eclipse.e4.ui/tests/org.eclipse.e4.ui.tests/test.xml?view=co&content-type=text%2Fplain