Re: Extension Points in NUnit 2.5

The trick with Gallio's R# support is that it will only work for frameworks
that are implemented on top of the reflection layer.

So unless NUnit is implemented on that layer or has its own layer that can
be adapted, Gallio will be unable to support it natively inside R#.

So for example, xUnit.Net has a very thin reflection API consisting of
ITypeInfo and IMethodInfo that provide most of what xUnit.Net needs so far.
When integrating xUnit.Net into Gallio, I just wrote adapters for their
reflection API.  Consequently xUnit.Net can be run by Gallio inside R#.

Of course, Brad and James already provide a R# plugin of their own...
However, using Gallio to run xUnit.Net inside R# still provides an advantage
because my R# reflection wrappers are probably much more robust.

Jeff. 

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Charlie
Poole
Sent: Friday, February 29, 2008 2:42 PM
To: [email protected]
Subject: Re: [nunit-developer] 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/
_______________________________________________
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/