Exactly. If you pass a wildcard that filters out everything then you
end up without tests. This isn't an error condition (to me).
I can add an option to the runner to fail on zero executed test cases
but then Robert's example won't work. I don't think there is any
sensible way to do it across "modules" -- aggregation would be very
difficult because every ant call is pretty much isolated and doesn't
know anything about the past/future. It'd be extremely hacky.
If you need to filter out a test case for a particular module, cd to
that module and run your tests there -- then your command line will
end with the number of test cases actually run. If you're running from
the top level then filtering just shouldn't fail -- it's very likely
that one module or another won't contain any tests matching your
filter. You can always resort to Mike's pythacks and spawn your tests
from there.
Dawid
On Mon, Oct 14, 2013 at 5:01 PM, Robert Muir <rcm...@gmail.com> wrote:
> I know understand why Dawid tried to make it clear that this stuff is
> wildcard matching.
>
> <!-- Aliases for tests filters -->
> <condition property="tests.class" value="*.${testcase}">
> <isset property="testcase" />
> </condition>
>
> Its sorta like shell expansion on the unix prompt: 'echo *' shouldnt
> return non-zero because there are no files in the current directory.
> thats because its very general and has a lot of use cases. On the
> other hand, it makes sense that 'ls *' returns 1 in this case, because
> its sole purpose is listing files.
>
> The same can be said for your python test-repeater
>
>
> On Mon, Oct 14, 2013 at 10:41 AM, Michael McCandless
> <luc...@mikemccandless.com> wrote:
>> This has actually bit me before too ...
>>
>> I mean, sure, I do eventually notice that it ran too quickly and so it
>> was not in fact really SUCCESSFUL.
>>
>> Why would Rob's example fail? In that case, it would have in fact run
>> TestIndexWriter, right? (Sure, other modules didn't have such a test,
>> but the fact that one of the visited modules did have the test should
>> mean that the overall ant run is SUCCESSFUL?). Is it just too hard
>> with ant to make this logic be "across modules"?
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Mon, Oct 14, 2013 at 9:41 AM, Shai Erera <ser...@gmail.com> wrote:
>>> I see, didn't think about that usecase. Ok so let's not do it.
>>>
>>> Shai
>>>
>>>
>>> On Mon, Oct 14, 2013 at 4:27 PM, Robert Muir <rcm...@gmail.com> wrote:
>>>>
>>>> On Mon, Oct 14, 2013 at 9:11 AM, Shai Erera <ser...@gmail.com> wrote:
>>>> >
>>>> > What's the harm of failing the build in that case?
>>>> >
>>>>
>>>> because i should be able to do this and for it to pass:
>>>>
>>>> cd lucene/
>>>> ant test -Dtestcase=TestIndexWriter
>>>>
>>>> So please, don't make this change. it would totally screw everything up
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
