Re: How do addon writers deal with NUnit versions?

Hi Stefan,

> > The problem with versions is a tough one. In theory, you should use 
> > only the nunit.core.interfaces assembly, but almost nobody 
> does that, 
> > since it seems much simpler to inherit from the 
> implementation classes 
> > in nunit.core itself.
> 
> Hmm.  XMLUnit is more of an Addon than an Addin following the 
> definitions on your site.  It really only adds new Assert 
> classes and probably (I need to check) only uses Assert itself.

OK - that's slightly different, since we're now talking about
nunit.framework, which is presumed to change whenever a user
wants to change it. NUnit itself protects itself by not having
any references at all to nunit.framework and using reflection.

> My preferred usage would be to use XMLUnit as a library and 
> don't use its Assert classes at all, but that's not what the 
> original authors intended.
> 
> Anyway, my problem is not API stability but the far more 
> annyoing problem that people writing tests using XMLUnit 
> 0.3.1 and NUnit 2.4.7 will get a FileLoadException since 
> XMLUnit 0.3.1 has been compiled against 2.4.6 (and at least I 
> can't find a way around that apart from releasing a new 
> XMLUnit version whenever you release a new NUnit version).

Of course, this makes sense from the point of view of .NET, 
since XMLUnit might be using some method that exists in
2.4.6 but not 2.4.7. That's not very likely, so you could
use a binding redirect at the user test level to force it
to work. Alternatively, XMLUnit could use reflection, but
that's more trouble than it's worth, I think.

> > 2) Use or modify my nant script (http://nunit.org/?p=addins) to do 
> > your build.
> 
> I've seen that, thanks.

Of course, it's not relevant here since you are not doing an addin.

> > 3) I'm hoping to make 2.5 at least a little better than 2.4 with 
> > regard to addins. Try it while it's in alpha and beta and join the 
> > nunit-developer list
> 
> Subscribed.
> 
> > PS: Something to discuss on the developer list, if you are 
> interested, 
> > is whether we might want to bundle xmlunit with nunit.
> 
> I'll be there, but right now I think it isn't in the right 
> shape for it.
> 
> My plans for an XMLUnit 2.0 focus on a test framework 
> independent library and some test framework specific adapters 
> - maybe the NUnit adapter could ship with NUnit 3.x or 
> something.  But then again I know XMLUnit is not my top 
> priority OSS project (I'm quite a bit involved in other 
> places as well), so one never knows when 2.x might be more 
> than vaporware.

It's nice to be busy. :-)

I think this thread points out the need for separating the
framework part of NUnit into underlying capabilities and
various adapters that make use of them. That's implied
in the diagram I posted for NUnit 3.0, but hasn't really
been talked about much. The ability to test a constraint
and transmit an error doesn't really depend on Assert,
for example, and doesn't actually change from release
to release. I'll look into that more as I'm able to move
my effort from 2.5 to 3.0.

In the meantime, it seems to me that the ideal solution
would be for XMLUnit to be a library of constraints that
can be used through the normal NUnit Assert.That() syntax.
This would not eliminate the dependency but it would make
it more likely that a binding redirect would succeed.

Other than the fact that the user would have to modify
the test config, do you see any problems with use of
a binding redirect? I think you mentionned in an earlier
note on this thread that it didn't work, so maybe we
should examine why.

Charlie

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



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