Re: NUnit 2.5: What's In It Now

Hi Kelly,
 
> > > 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.
 
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).
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).
 
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.
 
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).
 
> Consider this use case of a data test (which is real, I did it> Thursday)... I want to iterate over all the files in a directory, and> validate things about the files if they are the right type and> version. I could do this with your proposed 2.5 like this:> > public static IEnumerable AFiles> {> get> {> DirectoryInfo di = new DirectoryInfo("c:/data");> List<FileInfo> list = new List<FileInfo>();> FileInfo[] files = di.GetFiles("*.*");> foreach(FileInfo fi in files)> {> if (TypeOfFileIsA(fi))> {> object [] parms = new object[1];> parms[0] = fi;> list.Add(parms);> }> }> return list;> }> }> > [DataSource("AFiles")]> public void TestAFiles(object a)> {> FileInfo fi = (FileInfo)a;> // Assert something about the file of type A.> }> > public static IEnumerable BFiles> {> get> {> DirectoryInfo di = new DirectoryInfo("c:/data");> List<FileInfo> list = new List<FileInfo>();> FileInfo[] files = di.GetFiles("*.*");> foreach(FileInfo fi in files)> {> if (TypeOfFileIsB(fi))> {> object [] parms = new object[1];> parms[0] = fi;> list.Add(parms);> }> }> return list;> }> }> > [DataSource("BFiles")]> public void TestBFiles(object a)> {> FileInfo fi = (FileInfo)a;> // Assert something about the file of type B.> }> > ====================================================> Now, if you have Assume, then you can refactor the above code to this:> > public static IEnumerable Files> {> get> {> DirectoryInfo di = new DirectoryInfo("c:/data");> List<FileInfo> list = new List<FileInfo>();> FileInfo[] files = di.GetFiles("*.*");> foreach(FileInfo fi in files)> {> object [] parms = new object[1];> parms[0] = fi;> list.Add(parms);> }> return list;> }> }> > [DataSource("Files")]> public void TestAFiles(object a)> {> FileInfo fi = (FileInfo)a;> Assume.That(TypeOfFileIsA(fi));> // Assert something about the file of type A.> }> > [DataSource("Files")]> public void TestBFiles(object a)> {> FileInfo fi = (FileInfo)a;> Assume.That(TypeOfFileIsB(fi));> // Assert something about the file of type B.> }> > =============================================> Now, I don't know about you, but I like the second version better. And> this is very clearly data testing, not Theory.> 
 
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;
 
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...
 
Cheers,
Gary
_________________________________________________________________
Win 100’s of Virgin Experience days with BigSnapSearch.com
http://www.bigsnapsearch.com

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