Inheriting Category (and other) Attributes from a base class

332 views
Skip to first unread message

Charlie Poole

unread,
Nov 3, 2010, 5:14:38 PM11/3/10
to nunit-...@googlegroups.com
Hi All,

Here's a change in test semantics I'm thinking of. The question is whether
it would be breaking for some of you - and whether it's a good idea at all!

Currently, those attributes that modify a test are only effective if used on
the actual test, not on a base class.

So, for example, this won't work...

[TestFixture, Category("Hot")]
public abstract class HotStuff { ... }

public class ReallyHotStuff : HotStuff { ... }

The TestFixture will be inherited, but the category will not.

Questions:

Should we allow this use of inheritance to work?

Should the same thing apply to other attributes as well?

Which attributes?

Charlie

Simone B.

unread,
Nov 3, 2010, 5:17:55 PM11/3/10
to nunit-...@googlegroups.com
Following the principle of least surprise I would rephrase the question like this:
 
is there any reason why all those attributes shouldn't be inherited?
 
I would say No for TestFixture and Category

--
You received this message because you are subscribed to the Google Groups "NUnit-Discuss" group.
To post to this group, send email to nunit-...@googlegroups.com.
To unsubscribe from this group, send email to nunit-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nunit-discuss?hl=en.


Charlie Poole

unread,
Nov 3, 2010, 5:38:01 PM11/3/10
to nunit-...@googlegroups.com
Good point. The only reason not to do it is because our use of reflection
to find attributes by name is more code-intensive than just locating attributes
in the normal way.

In 3.0, that reason will no longer exist, so I think we should pretty much allow
any inheritance that makes sense.

In 2.5, I'm inclined to limit changes to what's really needed right now and
to implement them as simply as possible.

One approach - I think this will work - is to change the call to
GetCustomAttributes
to use true (for inherit) but leave some attributes still defined with
inherit=false.
If I'm right, this would give an easy way to turn inheritance on and off on an
attribute-by-attribute basis. I'll run a test.

Charlie

Simone B.

unread,
Nov 3, 2010, 5:43:37 PM11/3/10
to nunit-...@googlegroups.com
I think the Inherited property of the AttributeUsageAttribute class might be of some use, too.

Yann Duran

unread,
Nov 3, 2010, 7:23:13 PM11/3/10
to nunit-...@googlegroups.com
+1 all inheritance

Hi All,

Questions:

Which attributes?

Charlie

--

Charlie Poole

unread,
Nov 3, 2010, 8:05:05 PM11/3/10
to nunit-...@googlegroups.com
Right, that's what I was referring to for individual attribute control
- although I
said 'inherit'.

Charlie

Charlie Poole

unread,
Nov 4, 2010, 12:24:42 PM11/4/10
to nunit-...@googlegroups.com
Hi All,

I have reactivated the bug regarding inheriting Categories in nunitv2. It was
previously moved to 3.0. Here's my plan, taken from
https://bugs.launchpad.net/nunitv2/+bug/655882 ...

* All NUnit attributes will have the AttributeUsageAttribute Inherited
named parameter set explicitly.
* Attributes intended to provide a unique value will use
Inherited=false. For example, NUnit
can only deal with one description per test, so Description will
not be inheritable.
* Attributes that can have multiple values, like Category, will
use Inherited=true
* Attributes that can be reused with no problem, like Explicit,
will use Inherited=true
* In spite of the above, any attributes for which there is a
possible breaking problem, will use Inherited=false

* NUnit will fetch attributes using GetCustomAttributes(true), which
will retrieve any base class
attributes that have Inherited=true and ignore those with
Inherited=false. (This is a change,
so it's the place where we will see any breaking problems.)

Charlie

Charlie Poole

unread,
Nov 4, 2010, 2:11:24 PM11/4/10
to nunit-...@googlegroups.com
Hi All,

Here is my first cut at which attributes recognized when applied to a
base class.
I've marked any changes - at least intentional ones...

Recognized...
Category (changed)
Datapoint
Datapoints
Property (changed)
SetUp
SetUpFixture
Teardown
Test
TestFixture
TestFixtureSetUp
TestFixtureTearDown
Theory

Not Recognized...
Description
ExpectedException
Explicit
Ignore
Combinatorial
Culture
MaxTime
Pairwise
Platform
Repeat
RequiredAddin
RequiresMTA
RequiresSTA
RequiresThread
Sequential
SetCulture
SetUICulture
Suite
TestCase
TestCaseSource
Timeout
Values
ValueSource

As you can see, there are not many changes. That's because I could see
that there
were a lot of complications involved in making the changes. More stuff
can be changed,
but I think it will need to be one item at a time, with tests (of course).

Charlie

Reply all
Reply to author
Forward
0 new messages