[jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of <include> in pom?

Max Rydahl Andersen max.andersen at redhat.com
Mon Jan 26 07:21:37 EST 2015


>>> It essentially runs through all the bundles in the running platfrom, 
>>> searching for (in this
>>> case) AllTests classes then adds them to the suite. The suite is 
>>> executed via junit and the
>>> all the tests individually executed. This works in both Eclipse 
>>> (using a single junit
>>> launcher) and in maven (by making the plugin a test plugin and 
>>> adding TestGatherer to an
>>> AllTests suite class).
>>
>> I'm not following what this class helps do that surefire not already 
>> does ?
>>
>> How would this be used to group tests within the same test plugin 
>> into something I can run ?
>
> Primarily the TestGatherer is meant for running tests while in 
> Eclipse. It has the added benefit of
> grouping all the tests together when building with maven.

...but with the disadvantage that if you are running multiple projects 
tests you will now have things grouped together one might not want 
grouped together.

> So, this is what happens as it stands with the TestGatherer:
> * In Eclipse I have lots of plugins open and I want to run all unit 
> tests in my workspace.
> * I create a junit-plugin launcher pointing to TestGatherer and 
> execute it
> * TestGatherer brings up an eclipse test IDE and hunts for all 
> 'AllTests' in the platform and
> executes them
> * In effect, I have run all the AllTest classes in the development IDE 
> using 1 junit test suite,
> rather than having to run them individually.

Okey - now I get the use of it. You can do the same in plain eclipse 
today, but only for one project at a time.

> The added benefit of this test-aggregating was that maven could also 
> just run this single test plugin
> rather than executing tests for all test plugins.

That then assumes zero preparation is needed for the tests by the mvn 
build...we got builds that download runtimes which is done by the mvn 
build not the tests them self.

> When I developed TestGatherer, Designer builds in Jenkins kept failing 
> during the testing phase
> due to a protocol error on the XVnc instance. If all test plugins 
> brought up the XVnc instance
> then the build was successful.

> As an XVnc instance is required for each test plugin, I made all of 
> our test plugins 'normal'
> plugins and only the aggregate-plugin (housing TestGatherer) a test 
> plugin. Consequently,
> only 1 instance of XVnc is created when Jenkins  builds/tests and is 
> responsible for executing
> all the tests.

I *think* that issue is solved today...

> This configuration for maven may not be appropriate for other projects 
> but it certainly has been
> helpful in Designer development for running all tests in Eclipse.

yeah, I grok its use now, but it doesn't allow grouping of tests..unless 
you call "everything in one group" for grouping :)

/max

> PGR
>
> - --
> Paul Richardson
>
> * p.g.richardson at redhat.com
> * pgrichardson at linux.com
> * mob: +44 (0)9780 869490


/max
http://about.me/maxandersen


More information about the jbosstools-dev mailing list