Re: Need Feedback: RequiredAddinAttribute

Hi Cory, 
> Charlie Poole wrote:
> > It seems "intuitive" that you could write "[MyTest, 
> > RequiredAddin("MyTestAddin")] and have NUnit give you some kind of 
> > report, but it's not that obvious how NUnit could 
> distinguish it from 
> > [MySetUp, RequiredAddin("MySetUpAddin")] assuming each is 
> on a method 
> > with the same signature.
> 
> For some reason, the RequiredAddIn just feels like overkill. 
> I mean, I get that the AddIn may not be accessible at run 
> time. But it feels like we are exposing plumbing of NUnit 
> code out. In other words, when else would this be useful 
> outside of having NUnit AddIns?

Nowhere else - that's what it's for.

The general idea, of course, is that addins are downloaded from
third parties and NUnit can't tell that your intent was in typing
[XYZ] without the addin installed. When we discussed this earlier
(I think on the dev list) some folks were concerned that a test
might simply pass in the absence of an addin.

An example: [Test, MaxTime(2000)]
If the MaxTime addin is not present, no test will be made to
ensure that the time taken for the test was less than 2000ms
and it will appear to pass. It should fail. It seems to me
that the (optional) use of [assembly: RequiredAddin("MaxTime")]
is a reasonable feature to provide for those shops that want
to make sure this doesn't happen.

> It seems there are a couple of ways we could also handle it. 
> First, if we are going to go with this, I like the idea of 
> being assembly-level only. 

That's my inclination

> Second, perhaps we could just do a 
> configuration-thing where one would list the add-ins they are 
> using in the config file, and the first thing the GUI does is 
> validate that all of the AddIns are present, stopping the run 
> if they aren't.

That's possible, although it requires adding some more syntax
to the config. Most people seem to be adverse to putting things
in the test config. Another option I like better would be to
put it in the .nunit file - if there is one.

> It also seems like you could just have:
> 
> [Test]
> public void TestAddInsPresent()
> {
>    Assert.AddInPresent("MyTestAddIn");
>    Assert.AddInPresent("MySetUpAddin");
> }

The separation that is enforced between the framework 
and the core would make that a real pain to implement.
The test would (somehow) have to reach into the 
environment under which it is running and see what
addins are installed. This is analogous to a javascript
program in the browser trying to get out of its sandbox.

Even though I expect to change that architecture in 3.0,
it's not something to undertake lightly right now, IMO.

Persoally, I like the declarative approach anyway.

> 
> Or even have it as part of setup. Seeing this:
> 
> assembly:RequiredAddin("MyTestAddin");
> 
> while it is readable, makes me not as sure. Perhaps if it 
> said "assembly:RequiredNUnitAddIn" I'd feel better. Well, 
> slightly anyway. ;)

Well, it is an NUnit addin and the attribute full name is
NUnit.Framework.RequiredAddin :-)

What do others think? Would changing the attribute name 
make it clearer?

Charlie

> --
> Cory Foy
> http://www.cornetdesign.com
> http://www.agileflorida.com
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge Build the coolest Linux based 
> applications with Moblin SDK & win great prizes Grand prize 
> is a trip for two to an Open Source event anywhere in the 
> world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Nunit-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nunit-users
> 



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/