views:

171

answers:

3

I created an extension method called HasContentPermission on the System.Security.Principal.IIdentity:

namespace System.Security.Principal
{
    public static class IdentityExtensions
    {
        public static bool HasContentPermission
            (this IIdentity identity, int contentID)
        {
            // I do stuff here
            return result;
        }
    }
}

And I call it like this:

bool hasPermission = User.Identity.HasPermission(contentID);

Works like a charm. Now I want to unit test it. To do that, all I really need to do is call the extension method directly, so:

using System.Security.Principal;

namespace MyUnitTests
{
    [TestMethod]
    public void HasContentPermission_PermissionRecordExists_ReturnsTrue()
    {
        IIdentity identity;
        bool result = identity.HasContentPermission(...

But HasContentPermission won't intellisense. I tried creating a stub class that inherits from IIdentity, but that didn't work either. Why?

Or am I going about this the wrong way?

+1  A: 

The extension method should be in a static class. Where is your static class? Does your code compile?

Raj Kaimal
Sorry. I edited the question to add the missing code.
Robert Harvey
+1  A: 

I suspect that it has something to do with the fact that you added an extension method to the existing System.Security.Principal namespace. Make sure that you reference the project that defines the extension method, or try it with a different namespace.

Greg
+1 for referencing the project...That was the problem.
Robert Harvey
+6  A: 

Make sure you've built the project containing the extension and added a reference to this project in your unit test project. Note that you've also got (I assume) a typo in your example in that the method isn't in a class. Make sure that any class that it is in is static. Finally, I would avoid putting methods into the official .NET namespaces. It can only be confusing to anyone coming after you who might think that the method is an officially supported method when in reality it is your own and contained within your project.

tvanfosson
Thanks. I forgot to add a reference to the main project in the test project. I always forget to do that. For some reason I always assume that, because both projects are in the same solution, that they are aware of each other.
Robert Harvey
While you're right on the facts, I have to disagree with your opinion about extending framework classes. This is their *primary* purpose.
Steven Sudit
@Steven - It's fine to extend framework classes. What's bad is putting those extensions in the framework namespace.
Greg
@Greg: Why?....
Robert Harvey
I would put them in a `MyProject.SecurityExtensions` namespace as well and that putting them in the .Net framework classes would be misleading. You have no way to know that is your custom extensions without going to the source. If it is in your own namespace, just hovering over it tells you it's bespoke.
Mark
@Steven - I'm not arguing that you shouldn't use extension methods to .NET framework classes. I just wouldn't put them in an official namespace. I'd use my own.
tvanfosson
@Mark: OK, but what if they are aspect-oriented, general purpose extensions? Putting them into your own specific project namespace (unless it's a library of extensions) wouldn't make much sense.
Robert Harvey
@Greg, tvan: Point taken regarding the namespace; I misread it as referring to the class being extended. Mea culpa.
Steven Sudit
@Robert Harvey: We have a `MyCompany.Core` assembly we carry around on all our projects. We put our extensions in there. If I hovered over a method that said "System.Security.Principal.DoSomething" I would expect to find DoSomething here http://msdn.microsoft.com/en-us/library/system.security.principal.aspx. If it said MyCompany.Core.SecurityExtensions.DoSomethig, I would know exactly where it is. I also would be more likely to CTRL+Click to get to the source if I knew we wrote it.
Mark
@Mark: Yes, that makes sense.
Robert Harvey