Re: Extension Points in NUnit 2.5

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/