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

[Nick Boldt]

TL;DR:

I think this is what we've said we should do:

1. Use new default patterns in parent pom for JBDS 9 (and 8.1 too):

	include = *Test*, *Test, *TestCase
	exclude = *Abstract*

2. If that causes test failures because running incorrectly named 
abstract stuff, they can refactor, add their own root pom overrides, use 
a TestSuite, or use @Ignore in test classes.

3. If the count of tests run suddenly DROPS because the pattern isn't 
running the correct # of tests, they can add their own root pom 
overrides, or use a TestSuite.

So say we all?

N

On 01/23/2015 10:18 AM, Max Rydahl Andersen wrote:
> On 23 Jan 2015, at 14:54, Fred Bricon wrote:
>
>> I am so +∞ on dropping the current patterns
>>
>> I wonder if tycho’s default patterns are enough *Test*, *Test,
>> *TestCase
>> https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-surefire/tycho-surefire-plugin/src/main/java/org/eclipse/tycho/surefire/TestMojo.java#n149
>> <https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-surefire/tycho-surefire-plugin/src/main/java/org/eclipse/tycho/surefire/TestMojo.java#n149>
>>
>> 1) abstract classes are not run by default. So if you called an
>> AbstractFooTest class which is not abstract, it’s on you.
>> 2) when Eclipse JUnit runner runs on a projects/packages, containing
>> suites and individual classes, it’ll run tests from suites and
>> ignore (duplicate) individual tests. If it’s a core JUnit feature,
>> then it should behave the same in surefire. That needs to be verified
>> obviously
>
> Last I checked this surefire just uses the naming pattern - no smart
> filtering is done.
>
> The fact include/exclude is on *.class and not actual class/package
> names make me think that has not changed.
>
>
> /max
>
>>
>>
>>> Le 23 janv. 2015 à 08:38, Max Rydahl Andersen
>>> <max.andersen at redhat.com> a écrit :
>>>
>>> On 22 Jan 2015, at 20:51, Nick Boldt wrote:
>>>
>>>> You can set your own <include> entries in your root pom. Then all
>>>> your
>>>> projects' tests will inherit those new rules.
>>>
>>> the intent of the parent pom is to avoid we have unnecessary
>>> duplication
>>> and conflicting approaches.
>>>
>>> So better if we can fix the parent pom if its not optimal than
>>> continue
>>> to get different
>>> additional unnecessary testing configs in the various pom's.
>>>
>>> /max
>>> http://about.me/maxandersen
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
> /max
> http://about.me/maxandersen
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com