Blog: Four Ways to test Expected Exceptions

[Charlie Poole]

Hi All,

It's here: http://blogs.nunit.com

Comments?

Charlie




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

[Brad Stiles]

Post by Charlie Poole
Comments?

I haven't had occasion to use this method of testing exceptions (though
to be fair, I can't remember the last time I used *any* method for
testing exceptions), but your explanation is clear, and its use seems
much clearer and more precise than the previous method. I'd much rather
use the new than the old, but that's true for other assertions, too.

After some initial apathy ("skepticism" is really too strong to describe
what I felt), I've pretty much started using the constraint methods
exclusively over the Assert syntax, sometimes even changing old test
code when I need to change what it's testing. It just makes my code so
much easier to read and parse. One other developer on my team, for whom
"skepticism" wasn't strong *enough*, has also switched after really
looking at the resulting test code, and output. :)

Brad



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

[David Jeske]

I find separating every single exception test into a different methods
inconvinent and unweildy, mostly because of the need to access local
variables. I usually use a codeblock like this sitting in a test function
with lots of other stuff. The block looks like this:

{
bool err = false;
try {
do_something();
} catch (MyException) {
err = true;
}
Assert.AreEqual(err,true, "Expected MyException");
}

I'd be happy for a more terse way to write this, but I don't see how to do
it while retaining the ability to access the test-function scope. Passing in
all the necessary arguments is just annoying.

Post by Charlie Poole
Hi All,
It's here: http://blogs.nunit.com
Comments?

[Charlie Poole]

Hi David,

I think I'm missing something... Why isn't that code equivaent to...

Assert.That( delegate { do_something() }, Throws.Exception<MyException>()
);

Charlie


_____

From: nunit-users-***@lists.sourceforge.net
[mailto:nunit-users-***@lists.sourceforge.net] On Behalf Of David Jeske
Sent: Saturday, August 02, 2008 12:01 PM
To: Charlie Poole
Cc: nunit-***@lists.sourceforge.net; nunit-***@lists.sourceforge.net
Subject: Re: [Nunit-users] Blog: Four Ways to test Expected Exceptions


I find separating every single exception test into a different methods
inconvinent and unweildy, mostly because of the need to access local
variables. I usually use a codeblock like this sitting in a test function
with lots of other stuff. The block looks like this:

{
bool err = false;
try {
do_something();
} catch (MyException) {
err = true;
}
Assert.AreEqual(err,true, "Expected MyException");
}

I'd be happy for a more terse way to write this, but I don't see how to do
it while retaining the ability to access the test-function scope. Passing in
all the necessary arguments is just annoying.


On Fri, Aug 1, 2008 at 5:43 PM, Charlie Poole <***@nunit.com> wrote:


Hi All,

It's here: http://blogs.nunit.com

Comments?

[David Jeske]

I admit that I have not experimented with anonymous delegates, but my
assumption about how they are implemented in the runtime say that I don't
expect they have access to local scope... that is, I don't expect I could do
this:

DbHandle db = Db.open()
Assert.That( delegate { db.do_something(); },
Throws.Exception<MyException>() );

If I can, then I should definetly switch to this syntax.


On Sat, Aug 2, 2008 at 4:38 PM, Charlie Poole

Post by Charlie Poole
I think I'm missing something... Why isn't that code equivaent to...
Assert.That( delegate { do_something() }, Throws.Exception<MyException>()
);

[Charlie Poole]

In fact, due to some compiler magic, that does work.

Charlie


_____

From: David Jeske [mailto:***@gmail.com]
Sent: Sunday, August 03, 2008 8:38 AM
To: Charlie Poole
Cc: nunit-***@lists.sourceforge.net; nunit-***@lists.sourceforge.net
Subject: Re: [Nunit-users] Blog: Four Ways to test Expected Exceptions


I admit that I have not experimented with anonymous delegates, but my
assumption about how they are implemented in the runtime say that I don't
expect they have access to local scope... that is, I don't expect I could do
this:

DbHandle db = Db.open()
Assert.That( delegate { db.do_something(); },
Throws.Exception<MyException>() );

If I can, then I should definetly switch to this syntax.



On Sat, Aug 2, 2008 at 4:38 PM, Charlie Poole <***@pooleconsulting.com>
wrote:


I think I'm missing something... Why isn't that code equivaent to...

Assert.That( delegate { do_something() }, Throws.Exception<MyException>()
);

[David Jeske]

On Sun, Aug 3, 2008 at 9:43 AM, Charlie Poole

Post by Charlie Poole
In fact, due to some compiler magic, that does work.

Nice, then I should start doing that...

Any chance this works?

[ExpectedException(MyException)] delegate { db.do_something(); }

[Charlie Poole]

'fraid not.


_____

From: David Jeske [mailto:***@gmail.com]
Sent: Sunday, August 03, 2008 12:33 PM
To: Charlie Poole
Cc: nunit-***@lists.sourceforge.net; nunit-***@lists.sourceforge.net
Subject: Re: [Nunit-users] Blog: Four Ways to test Expected Exceptions


On Sun, Aug 3, 2008 at 9:43 AM, Charlie Poole <***@pooleconsulting.com>
wrote:


In fact, due to some compiler magic, that does work.


Nice, then I should start doing that...

Any chance this works?

[ExpectedException(MyException)] delegate { db.do_something(); }