Re: Extension Points in NUnit 2.5

Hi Jeff,

Thanks for all that info.  It does sound quite hard to work with
and possibly limiting, but I'll investigate further. 

Their lack of native support for NUnit actually hurts them. It
has come up with several of my clients, who were evaluating
Resharper. I tell folks they should get it anyway, but just not
run tests that way - or not rely on them completely anyway.

I'll take a look at the sdk and see about adding this to the
3.0 roadmap. If Gallio actually ends up running NUnit with
all its options and addins, that may be an alternative as well. :-)

Charlie

> I dunno what JetBrains plans for NUnit v3 look like, but I 
> imagine they'll probably just keep growing out their existing 
> NUnit adapter layer with hardcoded attribute names.  So 
> addins probably won't work.
>
> Writing your own R# plugin is really the best way to ensure 
> that all of your framework (including extensions) is 
> supported inside R#.
> 
> However, writing a R# plugin is a LOT of work!
> It also has significant design implications for the framework itself.
> 
> The problem is that in order to get annotations in the R# 
> code editor (click here to run this test), you have to be 
> able to derive test stucture from the R# metadata and code 
> model objects.  The Unit Test Explorer plugin you write will 
> receive from R# one of its internal objects, like an 
> IMetadataAssembly or an IProject.  It won't receive an 
> Assembly or Type object per standard .Net reflection.
> 
> So one way to write a plugin is to use the R# metadata and 
> code model objects directly.  But then you basically end up 
> writing the same test enumeration logic 3 times: one for your 
> framework's standard implementation using .Net reflection, 
> one for the R# metadata Api and one for the R# code model Api.
> 
> For Gallio I followed xUnit.Net's lead on this one and 
> created an abstract reflection Api.  However, since MbUnit 
> (and consequently Gallio's) feature set is significantly 
> larger than xUnit.Net's I basically ended up having to 
> recreate the whole reflection Api in this way.  Generic 
> parameters were a pain.
> 
> But the nice thing is that by using an abstract reflection 
> Api in Gallio, we can unify some paths that would be more 
> difficult using .Net reflection alone.
> 
> So for example, I have an ICodeElementInfo interface that is 
> the root interface for all of my reflection objects.  That 
> means assemblies, namespaces, types, fields, properties, 
> methods, events and generic parameters all have something in 
> common.  So when associating Tests with code elements 
> internally, I can use ICodeElementInfo instead of worrying 
> about having an Assembly for assemblies, a String for 
> namespaces, and a MemberInfo for other things.
> 
> Likewise, fields, properties, constructor or method 
> parameters and generic parameters are all targets for data 
> binding.  So they all implement a common ISlotInfo namespace 
> that unifies all of the slot-like behaviors: they all have 
> names, they have an ordinal index and they have a value type.
> 
> (What this means is that I can do RowTest-like data binding 
> to any kind of
> "slot".)
> 
> Supporting R# turned into this massive project of creating 
> (and testing) reflection wrappers.  But in the end, it did 
> make it easier to address many other cross-cutting concerns 
> in Gallio involving reflection.
> 
> In the end, it will also make it possible to do things like 
> inspect test assemblies that couldn't otherwise be loaded 
> normally by .Net.  For example, we could write a layer of 
> reflection wrappers for Cecil so we can just load test 
> assemblies as files from wherever they are located without 
> keeping any locks on the underlying files or having to deal 
> with weird Code Access Security limitations (compared to 
> using .Net's Assembly.ReflectionOnlyLoad).
> 
> Jeff.
> 
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On 
> Behalf Of Charlie Poole
> Sent: Friday, February 29, 2008 9:05 AM
> To: [email protected]
> Subject: Re: [nunit-developer] Extension Points in NUnit 2.5
> 
> I wasn't aware of their plugin architecture to tell the truth.
> 
> That's a function of the fact that I'm on a pretty tight 
> budget and so only use it when working on client machines - 
> which is mutually exclusive with doing NUnit development. :-(
> 
> Charlie
> 
> > -----Original Message-----
> > From: Jeff Brown [mailto:[email protected]]
> > Sent: Friday, February 29, 2008 1:45 AM
> > To: 'Charlie Poole'; [email protected]
> > Subject: RE: [nunit-developer] Extension Points in NUnit 2.5
> > 
> > You could always implement a R# plugin of your own...
> > 
> > Jeff. 
> > 
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of 
> > Charlie Poole
> > Sent: Thursday, February 28, 2008 3:05 PM
> > To: [email protected]
> > Subject: Re: [nunit-developer] Extension Points in NUnit 2.5
> > 
> > Resharper doesn't support extensions because they don't 
> actually use 
> > NUnit to run their tests. It's an unfortunate design 
> decision, in my 
> > view - and one I hope they will reconsider in the future.
> > 
> > I was not aware that TD.Net doesn't run extensions.
> > 
> > Charlie
> > 
> > > -----Original Message-----
> > > From: [email protected]
> > > [mailto:[email protected]] On 
> Behalf Of 
> > > Kelly Anderson
> > > Sent: Thursday, February 28, 2008 2:50 PM
> > > To: [email protected]
> > > Subject: Re: [nunit-developer] Extension Points in NUnit 2.5
> > > 
> > > I don't know if it's possible, but if we could make it easier for 
> > > TestDriven.NET and Resharper test runner and the like to support 
> > > extensions, that would be a good goal too.
> > > 
> > > -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/
> > _______________________________________________
> > 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/
> _______________________________________________
> 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/
> _______________________________________________
> 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/