Re: NUnit 2.5: What's In It Now
"Kelly Anderson" <[email protected]> Sun, 6 Apr 2008 20:58:19 -0600
| Newsgroups | gmane.comp.windows.dotnet.nunit.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sun, Apr 6, 2008 at 7:12 PM, Charlie Poole <[email protected]> wrote: > Hi Kelly, > > > I know that Assume is off your list for 2.5. But would it be > > possible to implement a couple of minor extension points that > > would allow for it in an Addin? It doesn't seem like that > > would be too hard, or take away very much from what Theory > > might develop into in the future. > > It seems as if there may be one or more misunderstandings > or what I'm saying - and maybe I'm also missing what you > are trying to say. Let me try to clarify this point by > point. > > 1) Assume is off my list as an independent feature, which > is how you proposed it. In fact, taken in that light, > it's off my list forever, not just for 2.5. I'm going to assume that you looked at my implementation of Assume. That is, it was exactly like Assert, except that it threw a different exception. How that exception gets handled by the framework is an independent question. Would your implementation of Assume be different than that? Or, are you simply saying that you don't want to release Assume without also releasing Theory. Do they need to be tied together to be useful? I guess I just don't understand if you didn't like the way I implemented Assume, or if you just have difficulty with doing it without some fuller approach to Theory first. I'm not trying to be confrontational, I just really don't understand the sense in which you are objecting to putting Assume in earlier rather than later... 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. > 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. > 3) What you were proposing in earlier discussions came > across to me - perhaps wrongly - as a sort of Potemkin > Theory implementation. That's what I reacted to, not > to the notion of you or anyone creating a true Theory > implementation as an addin. Go to it if you like. It's > just not in /my/ workplan for 2.5. Yes, that's what I understood. > 4) Earlier, in reacting to what I perceive as your > trying to push more and more into 2.5, at the expense > of getting started with 3.0, I reacted strongly. > Unfortunately, that reaction was taken by others as > discouraging their efforts. Nothing could be farther > from my intent. I understand the tension between putting more stuff in 2.5 and getting on with 3.0, I do. > I don't want to discourage you - not even, :-) - from > doing stuff either. In fact I encourage it. Have you > tried out Gary's Theory extension? Does it work for you? > Does it need something? Can you contribute whatever > that is? ... See, I'm encouraging you. :-) I have not yet tried Gary's extension, but I intend to do so as soon as I have a chance. Things have been a bit busy lately. -Kelly ------------------------------------------------------------------------- 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