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