Re: NUnit 2.5: What's In It Now

Hi Gary,


> > 2) As I mentionned in the earlier note, it's not hard
> > for someone to implement Theory as an extension using
> > the existing extension points. Gary has done that, in fact.
> 
> I'm not really talking about Theory, I'm talking about Assume. It's
> great what Gary has done, but without Assume, it's only half the
> story.
> 
 
My extension has assumes. My syntax is a bit worse than Assume.That, but the
functionality's there. It would take you about 5 minutes to make the changes
that you recently proposed to the list, but to do it in my extension; it's
just a case of putting the changes in TheoryMethod instead of
NUnitTestMethod.
 
That's the idea... If a particular test type understands a certain
exception, then the code to
interpret it belongs in the implementatio of that test type.
 
It's a little hard to see in 2.5, with the Test hierarchy living in the core
assembly, but 
NUnitTestMethod and NUnitTestFixture are not really part of the "core" of
NUnit, they
are extensions like any other, except for the fact that they are added to
the list
of extensions in a different way. In 3.0, they will be much more like other
extensions
and this will be easier to see.   
 
My implementation differs a little bit - your assume was simply a filtering,
but mine catches cases where none of the assumptions were exercised etc.
Nevertheless, it'd still be simple to change it to use Assume.That and catch
an AssumptionException, but all in the extension, and you could change the
behaviour to your preference.

I know you were asking Charlie the question, but I thought I'd chip in my 2p
on this (sorry for the diversion).
 
It seems worthwhile to me - hopefully to others as well. :-)
 
I was a bit lazy when I wrote my prototype Theory extension, my assumptions
were just a separate method that was called prior to the theory being
executed, but but I could have written them to work using the Assume.That()
syntax the same as you recently posted to the list. Your change was to be in
the NUnitTestMethod (I think, I'm working off the top of my head) to catch
the AssumptionException (maybe not correct name again).
 
That's an interesting approach. Way back, I was writing that there might be
more than one way to handle the detection of good data for a theory. It
sounds like you invented a way.
 
However, We've all derived from NUnitTestMethod in our paramaterized test
extensions, to handle the case of having a test with data, in my theory
extension I called it TheoryMethod (I think). and that would be the ideal
place to put the Assume functionality? i.e. it doesn't need to be in the
base class.
 
For the record, the lower down the hierarchy you derive from, the better off
you'll be. But of course, you'll have to write more
code, of course. It depends how you view Theory: as a special kind of NUnit
test, or as a sibling. If you derive from NUnitTestMethod,
then you will get whatever behavior it adds later on. That could be a
feature or a bug, depending.
 
 I think how you've written the Assume.That() and the exception handling is
good, but I think that we don't want Assumes to live in NUnitTestMethod -
does it make sense for a user to write an Assume in a vanilla unit test
(i.e. not even a RowTest or a DataSource test?). I haven't looked at the 2.5
sources yet, but I'm assuming that there is a derived class that the RowTest
and DataSource creates, ParameterizedTestMethod? Maybe that class, or a
Theory class deriving from that would be the better place to put this - but
this can be shipped with the Theory extension, and doesn't have to be in the
core/framework of NUnit, unless there's some reporting mechanism missing
(i.e. if we wanted a different way to report assumption failures, if we
bothered putting that functionality in).
 
In the current code, it's all handled in NUnitTestCaseBuilder and the new
ParameterProviders extension. The actual cases are
still NUnitTestMethods and the suite that holds the multiple tests is a
ParameterizedTestMethodSuite. I think some refactoring will be called for,
but I'd like some other eyes on the code for a bit of review first.
 
In part, the current structure is driven by my initial tests being for a
single execution of a parameterized test case, which I
represent as a single test, rather than as a suite with one member. It may
be that this "feature" will drop out at some point.
 
<snipped Kelly's example/> 
 
I can't see that this gives us much, we're using exceptions to control
program flow, which is slow, and we only save a line of code, i.e we could
have
 
if (!TypeOfFileIsB(fi))
  return;
 
That's how I saw it as well.
 
and it may be confusing for the users once they are used to seeing Assumes
for Theories? In a theory, Assumptions are powerful as they tell us the
cases for which we know our theory is not valid, but putting them in a
general test feels strange.
This is only my opinioni and gut-feeling though, it might be that users are
totally happy with this? I don't know...
 
+1
 
Charlie
 
Charlie
  
Cheers,
Gary



  _____  

News, Sports, Entertainment and Weather on your mobile. Text MSN to
<http://mobile.uk.msn.com/pc/msn_content.aspx> 63463 Now.

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

_______________________________________________
nunit-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nunit-developer