Re: Blog: Four Ways to test Expected Exceptions

"Charlie Poole" <[email protected]> Sat, 2 Aug 2008 16:33:31 -0700
Newsgroups gmane.comp.windows.dotnet.nunit.user
Message-ID <006d01c8f4f8$2e819490$6401a8c0@ferrari>
Hi Brad,

They have a few small features like that one - for example
the range assertion - that are obvious wins. We'll add similar
features.

What I like especially about xunit is the clean approach
to user-side extensibility using attributes. I adopted a 
similar approach for the inline parameter data attributes 
in NUnit, to see how it would work out and I think I'll
do more of that the next time around.

The "not doing" stuff part of it is very useful as a
demonstration of what really need and don't need in
a framework. Sometimes, people want to do them anyway,
either because they are using the framework outside
it's originally intended scope or from just plain
cussedness. I used to be more into the idea of 
restricted toolsets than I am now.

Regarding construction... one object per case is the
traditional approach. See junit for example. NUnit
broke with that - I don't know the reason actually.
Now it's a "feature" and hard to change as such. I'm
looking at having a sort of "isolation" level where
you could, among other things, indicate you wanted
a separate object per test case.

Charlie
> 
> Sorry for the cross-posting of the other note.
> 
> In the referenced blog entry, you mention that you "borrowed" 
> the Assert form of exception checking from xunit.net.  Are 
> there any other features of that framework that you plan on 
> borrowing?  
> 
> I checked it out when it was first announced, and there 
> didn't seem to be anything there that would make me want to 
> switch, though if I were newly in the market for a testing 
> framework, it would probably be at or near the top of the 
> list.  A good bit of it seems to be about *not* doing some 
> things, and frankly, it's just as easy for me to not do those 
> things in NUnit as it would be to switch to xunit.net and not do them.
> 
> The one that did jump out at me was the instantiation of a 
> new object for each test.  A quick tests reveals that NUnit 
> does not do that, and while I haven't run into any problems 
> so far with side effects, I can see where some sneaky things 
> might slip through.  Again, since I haven't had a problem, 
> it's not likely to make me switch, but it does look like a good idea.
> 
> 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=/
> _______________________________________________
> Nunit-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nunit-users
> 



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