ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Levy Lambert <anto...@gmx.de>
Subject Re: svn commit: r1588563 [4/16] - in /ant/core/trunk: ./ manual/ manual/Types/ src/etc/testcases/taskdefs/ src/etc/testcases/taskdefs/optional/ src/etc/testcases/taskdefs/optional/antlr/ src/etc/testcases/taskdefs/optional/depend/ src/etc/testcases/taskde
Date Sat, 19 Apr 2014 21:48:42 GMT
Thanks for the great work Michael,

On Apr 19, 2014, at 1:51 PM, Matt Sicker <boards@gmail.com> wrote:

> You can use the ExpectedException rule exactly where you expect the
> exception to be thrown. Using the @Test(expected = foo.class) (or whatever
> the attribute name was) is for the whole method. Unless you're talking
> about larger methods being tested that can throw multiple exceptions, then
> that's a different story altogether.
> 
> 
> On 19 April 2014 04:59, Michael Clarke <michael.m.clarke@gmail.com> wrote:
> 
>>> 
>>> buildRule.executeTarget("test1");
>>> ==> could the BuildFileRule use a default (test name) for executeTarget?
>>>    buildRule.executeTarget();
>>> 
>> 
>> I'm not sure it can - the same build file is often used for multiple tests,
>> each calling a different target, so how would we know which target was
>> intending to be called? If we were to change the general testing practice
>> to have an individual build XML for each test then this would be fine,
>> although I'm not sure this would be the right way to go. Alternatively we
>> could have an executeTarget() method that executes a default target (e.g.
>> "test") or incrementally executes targets for that class ("test1" on first
>> call, "test2" on the second call"), but this seems like it would just be
>> introducing complexity into BuildFileRule to force a specific convention.
>> I'd be interested in other's opinions on this though.
>> 
I am fine the way the BuidFileRule currently works, I do not see the need to introduce new
conventions.

>> 
>>> //TODO assert exception message
>>> Here the rule ExpectedException would help
>>> 
>> 
>> Agreed, although the problem still remains that we're not asserting we have
>> the right exception: how do we know Ant hasn't thrown a build exception
>> about a missing attribute when the test is expecting it to throw a
>> BuildException about now being able to create a temporary file? Working out
>> the exception messages and moving to ExpectedException is currently planned
>> to be part of my second phase of migration. There are some tests where we
>> have multiple exception asserts grouped into a single method so I need to
>> spit these into individual methods to allow the ExpectedException rule to
>> be used, but I plan on doing this as part of the exception testing cleanup.
>> 
>> Thanks,
>> Michael
>> 
> 
> 
> 
> -- 
> Matt Sicker <boards@gmail.com>
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message