Re: Fwd: Addin SetUp question

Hi Kelly,

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

No, that interface is for runners to use.
 
> >  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.
 
> >  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.

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.

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

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

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.
 
> -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/
> _______________________________________________
> nunit-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nunit-developer
> 



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