On Tue, 26 Sep 2006, Matt Benson <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
