I have been taught to follow the Red->Greeen->Refactor pattern when doing TDD. There have been situations where this pattern have not been applicable though.

For instance, a test to make sure that a controller action method (ASP.NET MVC) does not have an Authorize attribute. Since the test is testing the absense of an attribute it will pass on the first go, unless an Authorize attribute is added only to have the test fail.

What I have done so far when testing for absense of said Authorize attribute is to write a test for it, then add the Authorize attribute just to make sure that the test actually works, then immediately remove the Authorize attribute.

Am I doing something wrong, or is this just the way it is; some tests will pass unless we intentionally add code to make the fail and then remove that particular code?

  • failing to compile is also failing the test Aug 15, 2014 at 17:41

1 Answer 1


So the situation is this: your method does not have an Authorize attribute. Why do you need to test this? There are an infinite number of negative assertions like this which could be made about any given entity, all of which are initially true. If you have a genuine need to test this, it's because it's a genuine problem somewhere - somewhere something is getting objects with a method with an Authorize attribute, and it shouldn't. That's the point at which to introduce the test. Not out of the blue. And that's the point - where you say, "this thing can't work if it's handed an object with a method with an Authorize attribute." where you figure out what should happen if it is handed such an object. Write that test. Don't write a test about your controller, which itself is really neutral about the presence or absence of the attribute. Write the test around the entity which genuinely cares about the attribute. Then make it pass.

  • My thinking is, we want to make sure no one adds an Authorize attribute to the action method since that could cause certain roles that should have access to the method to not have it anymore. Is this wrong? Is that not one of the reasons we write unit-tests; to make sure that changes to the code does not break / change the application? Even if I had (I don't, yet, still leanring) a full integration suite of tests, as well as UI unit-tesets, is this still a good thing to test? Aug 15, 2014 at 17:54
  • 1
    @user1323245 - In that scenario, you don't test for the lack of Authorize attribute, you test that the role has access. If someone adds [Authorize], then the "role has access" test will fail.
    – Bobson
    Aug 15, 2014 at 18:02
  • 1
    @Bobson Yes. Of course. You are right. I actually have those checks in place. The controller has an Authorize attribute on it, and even though I have a test on a certain action method to make sure it doesn't have an Authorize attribute on it I also have tests to make sure that the correct roles do have access, which is what actually matters. Stupid of me. Aug 15, 2014 at 18:09
  • using some line breaks can make your posts that much more readable.
    – jwenting
    Sep 3, 2014 at 6:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.