Unit Testing Custom Attributes

What aspects of your custom attribute do you want to test exactly?

 

It is a start - a bad one. Focus on the purpose and outcomes of your testing, not on turning lines of code green. Use coverage as a tool to help you realise when you overlooked a property of your system (e.g. 'oh, I forgot to write tests that capture how the code should behave when given invalid inputs'), don't use it as a goal or an indicator of quality.

Try these questions:

• What are the situations in which your custom attribute will be used, that you want to verify are working as designed?
• What properties of the way the attribute works are most at risk of being broken by future evolution of the system?
• Does the attribute itself have significant functionality, or is most of the functionality actually in the code which uses the attribute?

Ultimately an attribute is like any other class - you can do

new MyCustomAttribute()

and access members on it - and if necessary you can also create dedicated classes in your tests which you apply the attribute to.

 

Code (CSharp):

1. class MyCustomAttributeAttribute : System.Attribute
2. {
3.     public int Value { get; }
4.     public MyCustomAttributeAttribute(int value)
5.     {
6.         Value = value;
7.     }
8. }
9.  
10. class TestClass
11. {
12.     [Test]
13.     public void TestMyCustomAttribute()
14.     {
15.         var attr = new MyCustomAttributeAttribute(5);
16.         Assert.That(attr.Value, Is.EqualTo(5));
17.     }
18. }

 

You never said anything about wanting to check that it was used. You said you wanted 100% code coverage, which my example provides.

Which brings us back to "focus on the purpose and outcomes of your testing," and the questions I originally asked you:

• What are the situations in which your custom attribute will be used, that you want to verify are working as designed?
• What properties of the way the attribute works are most at risk of being broken by future evolution of the system?
• Does the attribute itself have significant functionality, or is most of the functionality actually in the code which uses the attribute?

Neither I nor anyone else is going to be able to effectively help you if you do not explain what you are trying to accomplish. "Unit test a custom attribute" is too vague to be meaningful.

EDIT: To put it another way: you said that you're familiar with BDD. So what are the BDD testcases that you are trying to encode?

 

That doesn't sound like any definition of code coverage I've ever seen, but never mind, let's focus on the problem you're actually trying to solve here.

What I think you're saying is: you want to create unit tests that verify that your custom attribute is only applicable to the intended types of target - i.e. that you can put the attribute on a class, but that you can't put it on e.g. a property.

Is that accurate?

 

In that case, I think the only unit test that makes sense is one that retrieves the AttributeUsageAttribute from your attribute class and checks that its ValidOn property has the value you expect. Testing anything more than that is testing 'does the compiler work correctly', and there's no point in you writing tests for the compiler.

Code coverage is about measuring how much executable code has been exercised (whether it's counting lines of code, functions, branches, etc). There's nothing executable about your declaration that the attribute only applies to certain program elements - it's just marking up the type for the compiler - so code coverage is not a relevant concept.

Correct. Measuring "did the code that returns the string get executed" is code coverage, but testing "did the string have the expected value" is simple data testing.

 

Test coverage is not the same thing as code coverage. There are many different kinds of test coverage; code coverage is only one of them. There's also - for example - state space coverage, environment coverage, data coverage, etc.

Anyway, I simplified your tests. There is no point having the CheckAttributeCount test because the compiler will prevent you from having multiple AttributeUsage attributes on a single attribute class. You also do not need to use UnityTest because your tests do not need to be executed across multiple frames.

Code (CSharp):

1.  
2. public class MyAttributeTest
3. {
4.     private AttributeUsageAttribute attribute;
5.  
6.     [SetUp]
7.     public void Setup()
8.     {
9.         attribute = Attribute.GetCustomAttribute(typeof(MyAttribute), typeof(AttributeUsageAttribute), false);
10.     }
11.  
12.     [Test]
13.     public void CheckNoMultiple()
14.     {
15.         Assert.IsFalse(attribute.AllowMultiple, "Allow multiple is not allowed.");
16.     }
17.  
18.     [Test]
19.     public void InheritedIsTrue()
20.     {
21.         Assert.IsTrue(attribute.Inherited, "Attribute must be inherited.");
22.     }
23.  
24.     [Test]
25.     public void AttributeIsClass()
26.     {
27.         Assert.AreEqual(AttributeTargets.Class, attribute.ValidOn, "Attribute Target can only be used on a Class.");
28.     }
29. }
30.  

 

You could certainly write a test for "Does _TestInvokeMethod have the expected value" (though I think it's not likely to be a very valuable test, especially given that in modern C# you'd use the

nameof

operator to set the constant value instead of writing a string like that). But tooling which measures 'code coverage' (such as Visual Studio, or JetBrains dotCover) will completely ignore your declaration of _TestInvokeMethod when calculating a coverage percentage, because there's no executable code on that line.