Re: Fwd: Addin SetUp question
"Kelly Anderson" <[email protected]>
| Newsgroups | gmane.comp.windows.dotnet.nunit.devel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Mar 5, 2008 at 12:49 AM, Charlie Poole <[email protected]> wrote: > Hi Kelly, > > > When you say "from outside" I assume you mean in the context > > of actually writing tests. > > No, that interface is for runners to use. Oh, that helps me make what you said make more sense. Thanks for the clarification. > > > For extensions, we need to have the same thing - and in fact we do. > > > > I assume here that you're defining this as something > > different than "outside"... indeed, it may be a different > > "side" of NUnit, but it is still an "outside" side, if you > > follow my meaning. > > I think I do... Extensions are outside of NUnit in one sense, > but part of it in another. What I'm trying to get across here is that there are (at least) two APIs that people typically deal with in programming with NUnit. The first of these is the API you use when writing tests (Assert and the like). The second is used when you are extending NUnit. My simple suggestion is merely that we keep these two APIs as independent and self contained as possible so that when you are involving yourself in one or the other of these activities, it is very clear where to go for documentation, support, etc. I haven't been trying to make any deeper point than that, and I realize that you're probably already doing this. I just wanted to make the point that we should continue to keep them cleanly separated in 3.0. > > As open source, it is always going to be the case that people > > are going to crack it open and do things with it that we > > didn't anticipate. This is one of the things that I brought > > up in the rather tedious licensing thread from way back. > > There's a difference between what people can do and what we > will support. If someone uses things that are not part of the > documented external interfaces that's OK, but they're on their own. Sure. Sounds like a plan :-) > > It seems a good architectural vision to separate the > > "extensibility kit" from the "things you need to write your > > own tests", and separating them in documentation also seems > > like a good thing. > > You're confusing me here a bit. The "things you need to write > your own tests" are assertions and attributes. Those have always > been separate and weren't (I thought) what we were discussing > here. Are't we talking about the difference (for example) > between ISuiteBuilder and NUnitTestFixtureBuilder? I'm sorry to be confusing. Probably things are already clearly separated, and I'm beating a horse that died years ago. > > While I would normally argue against BDUF, the extension > > points seem like an area where it might not be a bad idea to > > do a fair bit of design up front. > > Well, we're using a package, so that leaves out quite a lot > of the design. If you mean designing what the extension points > will be, I agree that needs some work - although we could add > new ones later as well. I do mean designing what the extension points will be. The trick in creating good extension APIs is IMHO to be as absolutely generic and simple as possible. Make no assumptions that don't need to be made until they absolutely have to be made. The difficult part is getting different kinds of extensions to play nice with each other in ways that you may not be able to fully predict, like the recent issues relating to data-driven tests and assumptions about what were lists of tests, and what were single tests. I'm sorry if I'm being Captain Obvious on this thread. -Kelly ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/