Should we also exclude (by default) running integration tests? If so,
what pattern should be excluded? *ITest*.class? *IntegrationTest*.class?
N
On 01/23/2015 02:08 PM, Alexey Kazakov wrote:
On 01/23/2015 11:02 AM, Nick Boldt wrote:
> 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):
Let's do it for 9 (master) only.
>
> 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...
>>>
<
https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-surefire...
>>>
>>> 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(a)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(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>> /max
>>
http://about.me/maxandersen
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio