Re: NUnit 2.5: What's In It Now
"Charlie Poole" <[email protected]> Thu, 10 Apr 2008 12:28:30 -0700
| Newsgroups | gmane.comp.windows.dotnet.nunit.devel |
|---|---|
| Message-ID | <01d801c89b41$10274e10$6401a8c0@ferrari> |
Hi Kelly, > > > How do I, as a casual user, learn that I can't call > > Assume.That > > inside of a Test? I could assume that it would in > a > particular way, > > and it wouldn't. How do I discover that > fact as a casual user? > > > > The test would give an error due to the unexpected exception. > > That would help, IF the error were specific enough... something like > > "Assume is not supported within [Test], it is for use with > [Theory] only." It would say UnexpectedExcepton: AssumeException with any message you had provided and a stack trace. The user might have to wonder about it a bit before realizing that Assume is throwing the exception. That's a drawback, but I can't think of any other way to do it without lettin NUnit know that Assume exists. NUnit doesn't know anything about Assert either, btw. > If we're doing it for csUnit and MSTest, why would MbUnit be > a second class citizen? Just curious. Is it because it's > hard, or confusing, or what? csUnit and MS Unit tests provide only one type of test. So emulating them just requires an addin with a new test type. At least on the surface, mbUnit seems to provide many types of tests, so it's probably easier to emulate them separately, rather than to emulate "mbUnit" as a whole. Additionally, there seems to be no advantage for NUnit in emulating mbUnit as a framework, as opposed to emulating the individual fixture types. > > There > > are three levels we could do this at: > > > > 1) Have attributes and tests that look like MbUnit's > > 2) Simulate loading of mbUnit tests, execute their actual > > asertions and interpret the results. > > 3) Write some sort of adapter that runs the tests under > > the actual mbUnit runner and interpret the resultss. > > I was thinking along the lines of 3. It's certainly possible. > > (1) is how Andreas' RowTest works - as well as MbUnit's > > emulation of NUnit. > > Kind of weird to have NUnit run MbUnit to simulate running > NUnit... :-) One reaso why emulating All of mbUnit doewsn't make sense to me. > > (2) is how my csUnit and (in process) vsts addins work. > > (3) is how Gallio works > > > > For now, I'm sticking to (1) and (2) but we may go farther > in NUnit > > 3.0. > > I wouldn't expect anything on this line until 3.0. Adding > some data-driven stuff in 2.5 is really good, but not > emulation of MbUnit. I may add one or two fixture-type emulations, merely as a way of exercising the addin facility. Or maybe not - it depends on time. > Let's get it out. :-) Then Gary and I can play around with Theory in > Addin land. Continue to do it now as well - there may be changes needed in 2.5 to make it work. Charlie > -Kelly > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by the 2008 JavaOne(SM) > Conference Don't miss this year's exciting event. There's > still time to save $100. > Use priority code J8TL2D2. > 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 > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone