unit testing and SRP (test method scope/organisation)

Say I have an MVC Action like:

public ActionResult CustomerRecord(customerId)
{
    if (_cu开发者_JAVA百科rrentUser.CanViewCustomer(customerId))
        return View();

    else 
    {
        // user has tried to access an unauthorised record, 
        // should not be here!
        _logger.Log(new SecurityException());
        return View("UnauthorizedAccess");
    }
}

To test the case of an unauthorized access attempt, how many test methods should there be?

i.e. do I write a single test:

CustomerRecord_WithUnauthorizedUser_LogsExceptionAndReturnsUnauthorizedView

or do I write two tests:

CustomerRecord_WithUnauthorizedUser_LogsException
CustomerRecord_WithUnauthorizedUser_ReturnsUnauthorizedView

I guess the problem is that technically the controller violates SRP, but I don't see that as being a problem in itself (please correct me if you disagree). I'm just not sure how that maps to test methods. One test per responsibility of the method, or one test per single route through the method?

---

Your controller isn't necessarily violating SRP by doing two things - it's still only got one responsibility (controlling).

In this specific example, I would caution against asserting that a log call is made - it's not going to affect the functionality of your application if you take out the log statement. Overspecifying unit tests makes them brittle and a pain to maintain, which is part of the reason I like BDD so much.

If you had to audit every failed attempt then I guess that's worth unit testing, so if that's what you're doing then read on:

In general, you should only have one assertion (maybe you'd have to call an Assert method or two to make one semantic assertion) per unit test - basically because it's nice to be able to look at the name of the failed test and to know exactly what's gone wrong without having to look at the code. So I'd advocate having two tests...

---

I prefer the one assert per test (or responsibility as you put it) because it's instantly clear what part of the code path has failed if there is a problem. This assumes you name your tests (your examples do) in a way that's understandable when reading your test results.