[antunit] included/excluded tests patterns

[Matt Benson <gu...@yahoo.com>]

When writing antunit tests, one cannot use the
log-inspection assertions or the new au:logcontent
resource outside the context of an AntUnit test.  This
is understandable/unavoidable, but it does mean that
there are some tests that cannot be developed with
'ant -f ...'.  Obviously you could write new tests in
separate files, but when they share setup with other
tests, that is inconvenient.  I was thinking of adding
a means of [in|ex]cluding tests to be run.  To that
end, it seems like it would be easy to use PatternSets
for this; it also seems like this is the kind of weird
idea I have that scares people, so I'm bringing it up
on the list.

So if file test.xml had tests "testFoo", "testBar",
and "testBaz", you could do things like

<property name="antunit.includetests"
          value="test?*" />
<property name="antunit.excludetests" value="" />
<antunit includetests="${antunit.includetests}"
         excludetests="${antunit.excludetests}">
  <resources refid="testfiles-defined-elsewhere" />
</antunit>

nested includes/excludes could be supported something
like

<antunit>
  <resources refid="testfiles-defined-elsewhere" />
  <testpatterns><!-- here's a nested patternset -->
    <include name="testFoo" />
  </testpatterns>
</antunit>

Hopefully you get the idea.  How crazy is this?  I
recognize the semi-evil of how I specified the default
includes "test?*" above, but that was weighed against
the evil of using "target pinball" to choose one of
two separate <antunit> invocations, and since this is
obviously more of an expert feature I really don't
feel too bad about it.

-Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: [antunit] included/excluded tests patterns

[Dominique Devienne <dd...@gmail.com>]

> Hopefully you get the idea.

Uh, not really ;-)

> How crazy is this?

Not crazy to me, because I implemented this once in the past on top of
JUnit (if I half-undertood you). I had a custom TestRunner that
accepted an additional -m testMethod switch. It slowly died when the
new version of JUnit came out, with heavy refactoring of TestRunner.

But really I don't understand what's broken with AntUnit as you
describe (or not!). --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: [antunit] included/excluded tests patterns

[Stefan Bodewig <bo...@apache.org>]

On Tue, 26 Sep 2006, Matt Benson <gu...@yahoo.com> wrote:

> When writing antunit tests, one cannot use the
> log-inspection assertions or the new au:logcontent
> resource outside the context of an AntUnit test.  This
> is understandable/unavoidable,

Is it?  We could add a task that registers a LogCapturer with the
current project.  We'd lose the log before the task was run, but that
should be fine for most antunit tests.

> but it does mean that there are some tests that cannot be developed
> with 'ant -f ...'.

Unless you add a target running antunit in the file to the file itself
...

> I was thinking of adding a means of [in|ex]cluding tests to be run.

Independent of the problem above, I've been thinking about this
myself.  The reason is the current failure of the antbook examples in
Gump.  The failing AntUnit test cannot pass in Gump since it assumes a
classpath setup that's not available here.

The alternative to an approach that selects targets to be run in the
task (as you suggest) is putting guards into the build file under
test, like we currently do in several JUnit tests

    public void testEcho() throws Exception {
        if (getProject().getProperty("nant.found") != null) {
            expectLogContaining("echo", "foo is bar");
        }
    }

would translate to 

    <target name="testEcho" depends="check.nant" if="nant.found">
        ...

> To that end, it seems like it would be easy to use PatternSets for
> this;

Interesting abuse of patternsets, but why not.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org