Re: [nunitv3] Assume Implementation
"Charlie Poole" <[email protected]> Tue, 8 Apr 2008 09:08:56 -0700
| Newsgroups | gmane.comp.windows.dotnet.nunit.devel |
|---|---|
| Message-ID | <000001c89992$d9db6c10$6401a8c0@ferrari> |
Hi Kelly, Responding to your proposal - now that you reminded me of it on the developer list. > As promised, I have attached my implementation of Assume. I > did this with the absolute minimum possible changes to the > other files, so the implementation is not optimal yet. It > does, however, work for regular Assume. I did not bother yet > to do Collections, Strings or File Assumes to match the > corresponding Asserts.... not sure if those are useful or not. My thought is that you should stick with Assume.That for this new feature. There is nothing you can do with the other Asserts that can't be done with Assert.That and Assume.That will inherit the same superset of functionality. <snipped code changes/> > Assume works just like Assert, except that it throws a > different exception. Which, in you code causes the test to succeed. That's an implementation detail I find troubling. I believe it needs to do something else to justify itself. > I would propose refactoring this code, pushing up a common > base class (Perhaps called AssBase? :-) that is inherited by > both Assume and Assert. Everything is moved up there, except > that there is a new virtual function called ThrowException > which either throws AssertException or AssumeException in > either subclass. Wherever the Exception is thrown in the base > class, call ThrowException. Then I think it's nicely done. I plan to put the key Assert components (That, Fail, Ignore) into a base class. The "classic" asserts would inherit from that. However, I don't think Assume.Fail or Assume.Ignore make much sense, so Assume may need to remain a separate class. Anyway, I prefer to create duplication in code before removing it - as opposed to just seeing it in my head as many folks do. > I didn't do that already because I wanted to make merging the > code in very easy for anyone wanting to experiment. Good idea. It would have made it pretty impossible for me to review as well. > Charlie, please feel free to add this to the code base if you like it. > Obviously, I'd rather do the suggested refactoring first, of course. > > The question of where to put the Assume message output is > obviously up for discussion. I did not implement anything > relating to multiple invocations of a test, including not > passing the test if it always fires Assume. A test that is run many times, with a sort of vote being taken on the results, is a candidate for a new type of test. Tests in NUnit are responsible evaluating their results - not the runner. So any logic like this will have to live in some special kind of test. The basic NUnit testcase passes or fails based on a single result. > On a side note, this is only the second time I've modified > code written by someone else under test. What a pleasure!! > Even though I did have to resort to using the Debugger to > figure out how the exceptions were handled :-) Cool! Charlie > -Kelly > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the > Google Groups "NUnitV3" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nunitv3?hl=en > -~----------~----~----~----~------~----~------~--~--- > > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone