Unit test Custom authorize attribute - asp.net-mvc

Question

I've written a custom claims authorizatize attribute and I would like to unit test the code I've written but have been unable to find what I'm looking for on SO.
For example, this is my custom authorize attribute class:
using System.Collections.Generic;
using System.IdentityModel.Tokens.Jwt;
using System.Linq;
using System.Security.Claims;
using System.Web;
using System.Web.Mvc;
using System.Web.Security;
using IPD2.MVC.Interfaces.Providers;
using IPD2.MVC.Providers;
namespace IPD2.MVC.Attribute
{
public class ClaimsAuthorizeAttribute : AuthorizeAttribute
{
private readonly string _claimValue;
private readonly string _claimType;
private readonly ITokenProvider _tokenProvider;
public ClaimsAuthorizeAttribute(string type, string value)
{
_claimType = type;
_claimValue = value;
_tokenProvider = new TokenProvider();
}
public override void OnAuthorization(AuthorizationContext filterContext)
{
var jwt = _tokenProvider.ApiToken as JwtSecurityToken;
if (jwt == null)
{
HandleUnauthorizedRequest(filterContext);
}
else
{
var claim = jwt.Claims.FirstOrDefault(expr => expr.Value == _claimValue);
var authCookie = HttpContext.Current.Request.Cookies[FormsAuthentication.FormsCookieName];
if (authCookie != null)
{
var formsAuthenticationTicket = FormsAuthentication.Decrypt(authCookie.Value);
if (formsAuthenticationTicket != null && !formsAuthenticationTicket.Expired)
{
var roles = formsAuthenticationTicket.UserData.Split(',');
HttpContext.Current.User = new System.Security.Principal.GenericPrincipal(new FormsIdentity(formsAuthenticationTicket), roles);
}
}
if (claim != null)
{
base.OnAuthorization(filterContext);
}
else
{
HandleUnauthorizedRequest(filterContext);
}
}
}
}
}
Test code
public class GivenCallingClaimAuthorizationAttribute : SpecsFor<ClaimsAuthorizeAttribute>
{
//HttpActionContext actionContext;
//IPrincipal originalPrincipal;
protected override void Given()
{
SUT = new ClaimsAuthorizeAttribute(ClaimTypes.Role, "ImNotAllowedToUseController :(");
}
public class WhenUserIsNotAllowedToAccessController : GivenCallingClaimAuthorizationAttribute
{
protected override void When()
{
SUT.OnAuthorization(
new AuthorizationContext()
);
}
}
[Test]
public void ThenAssertSomethingBasedOnCodeInTest()
{
//todo: some assert
}
}
I've written this basic test class with the SpecsFor BDD framework but I'm not sure what it needs to test it succesfully.
Any ideas on how to test this? As you can see, I'm testing the class itself rather than a controller with the attribute. I'm not sure about a good way to test this.

Answer 1

If you want to do BDD, think about the behaviour of your class. What kind of things should it be able to do?
For instance, perhaps it should:
- authorize current users
- filter users whose ticket has expired
- assign authorized users with the correct roles
- etc.
Let's say we're going to look at the second one of those, because it's interesting. I'll ask you, "Can you give me an example of when a ticket might expire?"
And you say, "Yes, the timeout is 500ms so anything older than that is expired." Or you say, "These are tickets to a football match and are given out yearly." (I don't know what a ticket is, but this conversation would help me work that out.)
So then we can write an example:
Given we've got a handler for unauthorized tickets
Given Fred's ticket expired on 2017-05-14
And it's now 2017-05-14
When we try to authenticate Fred
Then Fred should not be authenticated
And the handler should be given Fred's details
Next I like to put these in comments in code, with the "should" as the title of the test. After that, it's just a matter of setting up the context (in the Given), passing it to your code to exercise (the When) and verifying the outcome (the Then).
However, you can see that your Specs framework only allows for one given! That's not great, since I've already identified several scenarios which require different contexts. If you use SpecsFor the way you're using it, you'll have to make one class for each of my scenarios, and they won't be very easy to read!
I highly recommend using the second style instead, and start just with the Given, When, Then in comments.
The thing is, unit tests' steps aren't really reused much, compared to say a full-system BDD scenario, in which contexts are often called several times for different capabilities. A unit of code (or class) tends to fulfil one responsibility, or it gets refactored that way, and its contexts don't bleed into other classes because Mocks.
So, I find that just having Given, When and Then in comments is enough.
I therefore recommend you switch to the "old school" way of doing things that I can see in this page (down the bottom) and just start with the comments. See how that goes for you.
By the way, if you really want to do BDD properly, then you want to drive the development with the examples of how it behaves, and incrementally fill in the code to make those examples work, rather than writing them down. The book "Growing Object Oriented Software, Guided By Tests" will be very helpful for you.