Re: Extension Points in NUnit 2.5

Hi Kelly,

> >  > >  Exactly... trading off future usefulness versus effort.
> >  >
> >  > Getting it done right is, IMHO, better than getting it 
> done quickly.
> >
> >  I don't want to beat this to death, but "getting it done right" 
> > implies  NUnit 3.0 for me. For 2.5, the choice is between 
> "getting it done easily"
> >  and not leaving it for later.
> 
> But if we try to implement it in 2.5 won't we learn something 
> in the process that will enable us to make better decisions 
> for 3.0? I'm not saying that we should try to get it perfect 
> in 2.5, just that we should do enough to get feedback on the 
> concept from the community (and our own observations) that 
> might be helpful in making 3.0 better.

That could be true - and it's what I was trying to say initially.
However, since the implementation of addins changes completely
in 3.0, we could also be spending a lot of time on 3.0 work.

The way to make our mono.addins implementation work better is to
start doing releases that use mono.addins. By definition, that's
not 2.5.

So, to put some imaginary numbers on it, if 90% of the effort
will be obsoleted by use of mono.addins, I don't want to do it.
If only 10%, then I'm fine. Neither of us can know which
it is without making a start.
 
> >  That would mean you would have to mark each one of them, so it  
> > doesn't seem as if it would be worth the trouble. However, 
> it  might 
> > be possible to allow the attribute to apply on individual  
> tests, just 
> > in case someone wanted to use it that way.
> 
> I just hate to see the entire suite fail to run because 
> something needed by a small percentage of tests isn't there. 
> It makes it harder to track down what the problem is, and 
> it's psychologically difficult to see that sea of red all at once. :-)

Good. Red is supposed to mess your head up. :-)

I think this would be easy to implement in 2.5 and a more granular
approach could be considered in 3.0, because of some other changes
I see making.

> >  > I see. Can we determine the dependence and mark all dependent  > 
> > tests red? Or just put up some overall red output? Even  > 
> having the 
> > summation be red seems like it would be enough if  > there were 
> > feedback about the result.
> >
> >  There's no general way to determine the dependence. How an 
>  extension 
> > decides to apply itself is completely opaque to  NUnit and 
> there is no 
> > necessity that the test have any  sort of reference to the 
> extension.
> 
> Ok.
> 
> >  We discussed this at some length (somewhere) and I was 
> thinking  that 
> > the optional assembly attribute was a pretty good compromise.
> >  It's the same level of error you get if your test references an  
> > assembly that is missing: nothing loads, nothing works.
> 
> Seems like a fairly reasonable compromise. I won't stop 
> thinking about ways to make things better though. :-)

I'd expect no less. :-)

Charlie

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