Thanks for the great work Michael, On Apr 19, 2014, at 1:51 PM, Matt Sicker <boa...@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.cla...@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 <boa...@gmail.com> Antoine --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org