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

[Paul Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/01/15 15:31, Max Rydahl Andersen wrote:
> On 23 Jan 2015, at 14:58, Paul Richardson wrote:
> 
>> On 23/01/15 11:42, Max Rydahl Andersen wrote:
>>>> 
>>> One drawback of not having testsuites is though that we loose the ability to easily run a 
>>> group of tests from eclipse or maven.
>>> 
>>> Anyone found a good way of doing that via junit ? (testng has groups but tycho
>>> surefire/junit does not support that afaik)
>> 
>> Yes. Designer has had a test-aggregate plugin for all its junit tests for a while now. [1]
>> 
>> Based on an idea from my last job, the TestDesignerTestGatherer[2] class is a junit 3 style
>> test suite.
>> 
>> 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 ?
> 
> for me it looks like this one just picks up *all* test classes which is already possible today
> with junit launch to just have it run all tests found in a package or project ?
> 

In addition to my previous email, while I think a little further ...

TestGatherer currently finds and matches classes with name 'AllTests' in the platform. This is
just a constant
that could be modified on a case by case basis. For example, it could be an argument set via the
JUnit test
launcher which matches a specific group of tests or even looks for an annotation inside classes.

A configuration class could be added to specify the tests that should be executed on a
bundle-by-bundle basis
I suppose. My point is that TestGatherer being a java class that finds tests dynamically can be
modified to
suit individual use-cases.

HTH

PGR

- -- 
Paul Richardson

  * p.g.richardson at redhat.com
  * pgrichardson at linux.com
  * mob: +44 (0)9780 869490

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUwn86AAoJEG7P2ul73V7c0hMH/A+sTWXOFtuVDYy0eB+e2Wyl
GKKDrkG9YUfeRsx7dSv6lI/eWsipU5A+inZ1SojQJTfKNzeNeI8oF1OLza1Y42gk
RLkr0zzzS1m7Hf3AduR/6nmi+fXCa6cNgOUhJLVHld6IdZHlYQyWmk6u4sYBV53E
wNvjoM0Uay3Ycy4S9T47AtGjsouaunssGyIwcRzkb1DhNHYliZYXIfz8ucvZx3MB
P7pLSftK6injSYancB2pWtsyxGvEo0GkKFxY/FpWpThIxyEVklRMbHdcNSA2VV4c
OqPf4sM3O8ZgxoO35NPijEUNW+fmmmd8MYrAhxfd8Y9KRTWM8Li5gLpzifToD5M=
=jjvq
-----END PGP SIGNATURE-----