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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.