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.
>
>
> > //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>
