Re: Fwd: Addin SetUp question

"Kelly Anderson" <[email protected]>
Newsgroups gmane.comp.windows.dotnet.nunit.devel
Message-ID <[email protected]>
On Mon, Mar 3, 2008 at 6:50 PM, Charlie Poole
<[email protected]> wrote:
> Hi Kelly,
>  > I'm sure this is not lost on anyone, but what we think about
>  > as "internal" and what we think about as newly exposed
>  > extension points is an important design issue as we go
>  > forward. If it's to be useful in 2.x, the same probably
>  > applies, but I think it gets especially vital in the 3.0 time frame.
>
>  Yes. You'll notice that there is a big wided façade on top of the
>  engine in my "vision" block diagram. My view is that's the stuff
>  you should call from outside.

When you say "from outside" I assume you mean in the context of
actually writing tests.

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

>  However, it turns out that most people who want to implement extensions
>  do so by deriving from internal classes. That's understandable, since
>  it's the easiest way to do it. So I think we have to provide some
>  sort of minimal "extensibility kit" with the stuff that you need
>  to use to implement a test, for example.

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.

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.

>  > Yup. Again, this is a good reason to get the extension points
>  > in 3.0 as good as we can the first time around, as there
>  > won't be a really super good way to fix it until 4.0, which
>  > is hopefully years off.
>
>  Fortunately, mono.addins does have a way of versioning extension points.
>  But the actual action interfaces - the ones we create - will need to be
>  versioned as well.

Interesting. I hope it works better than COM versioning. :-)

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.

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