Testing ASP.NET MVC Filters

Testing controllers in ASP.NET MVC is straight forward.  However, testing action filters applied to controllers or actions requires jumping through a few hoops.  Since filters are applied by the framework, calling the action directly means no filters are executed.  Thus, you write two tests: one for the filter and one that the controller is decorated with the filter.

Testing controller actions is pretty simple:

  1. Instantiate the controller
  2. Invoke the action
  3. Test the result.

For instance:

However, you can’t use this same pattern for testing filters applied to actions or controllers. Filters are invoked by the ASP.NET MVC framework.  When you invoke an action directly on the controller, it does not execute the filters for the controller or the action.
For example, the following test case fails:

As mentioned above, to test filters you need to test two things:

  1. The filter is applied to you controller or action
  2. The filter code
Testing Filter Application
Using reflection, you can get get all the filters applied to an action or controller.  The following snippet shows how you could test that a filter is applied to an action. 
This code:

  1. Gets the action method from the controller
  2. Finds an attribute for the filter
  3. Checks that the method has a filter

Testing that controllers have filters applied is similar.  See the download at the end of this post for sample code.

Testing Filters

Testing filters is more complicated that testing controllers.  We need to:

  1. Mock up a filter context
  2. Create the filter
  3. Invoke the appropriate filter action
  4. Test the filter result

The following, using Moq, shows how you can perform these steps in a test:

Further reading:

Software Hierarchy of Needs

In my advanced placement high school history class, one of the first things we covered was Maslow’s Hierarchy of Needs. I no longer remember the reason, or how we used it over the course of the year, but the idea that there is a pyramid of needs where lower levels must be fulfilled before moving to a higher level of existence stuck with me. For instance, it is impossible to make law and order a basic part of you living unless the basic needs of food, drink and shelter have been satisfied first. Recently I’ve been thinking about Maslow’s Hierarchy of Needs Software Organizations – the building blocks that a software organization must fulfill before considering the next tier of professionalism and success.

Here are the five levels of needs that I think a software organization needs to be successful.

Level One – Basic Needs

  • Market Need
  • Requirements
  • Idea
  • Computer
  • Editor
  • Tools
  • Manual Testing

Level Two – Starting a Team

  • Build Process
  • Unit Tests
  • Souce Control
  • IDE
  • High Level Language
  • Team work

Level Three – Automation and Management

  • Bug Tracking
  • Project Management
  • Dedicated QA Team
  • Automated Build
  • Automated Testing
  • Design
  • Collaborative Environment
  • Product Management

Level Four – Professional Testing

  • Historical Test Results
  • Continuous Integration and Testing
  • Usability Testing
  • Performance Testing
  • Integration Testing

Level Five – Icing on the cake

  • Documentation

In my opinion, these are the building blocks of success for a software organizations.

Level One can be a guy with an idea working at nights to hack something together, but it isn’t built by a software professional. At Level Two we start to see some of the key pieces of a team coming together: source control for sharing code, an automated build process, basic automated desk checking to make sure you haven’t broken something and so forth. Level Three brings more professional practices including a QA team to automate builds and tests and product and project management to make sure you are building the right product on time. Level Four ensures quality and adds to the testing foundations from level three and makes sure if something breaks, it is known right away and trackable. Level Five is the nice to haves.


The Net Negative Producing Programer

It has been well known for a long time that there is at least an order of magnitude difference between the most productive developers and the least productive. But if you’ve been in the software industry for any period of time, you’ve probably met this person: the net negative producing programmer (NNPP). This is the person that is so bad, that they actually have a negative effect on team productivity: you would be better off not having this person on your team.

The NNPP drains a software development team and the business in a variety of ways:

  1. Initial hiring and training costs
  2. Ongoing mentoring from your top developers
  3. Unacceptably high defect rates
  4. Very low output, if any
  5. Lowers team morale (they make roughly the same amount of money as you)
  6. Causes the business to delay or miss deadlines
  7. Taking up a position that could be filled by a great programmer

So how do you identify and avoid the NNPP and what do you do if you are stuck with one?


The first step in ridding your team of the NNPP is identification. You may have an intuitive sense of who is the lowest performing member of you team, but this doesn’t necessarily make them a NNPP. The NNPP will exhibit a number of the following red flags over a significant period of time:

  • Takes a long time to get the development environment running
  • Codes by copy and paste
  • Reinvents the wheel
  • Doesn’t check in much code
  • Takes a long time between check-ins
  • Keeps saying the code is almost done
  • Tasks always take significantly longer than estimated
  • Has a high defect rate and/or significant defects
  • Doesn’t perform basic desk checking
  • Avoids responsibility / passes the buck
  • Doesn’t use/understand naming conventions
  • Asks questions that lack depth
  • Asks too many questions (unable to do things by themselves)
  • Doesn’t ask enough questions (works in a silo)
  • Doesn’t integrate with the team
  • Lacks passion for software development
  • Types slowly

New hires, junior developers may exhibit more of these and any programmer might exhibit some of these from time-to-time. For these
developers, they deserve time, mentoring and training to get them on
the right track. But if you have a senior software engineer consistently displaying
a lot of these characteristics, you have at least an over-paid, under-performing developer and likely an NNPP.

You can catch these red-flags through with a variety of techniques:

  • Performing Design Reviews
  • Performing Code reviews
  • Pair Programming
  • Measuring defect rate
  • Measuring estimates vs actual time
  • Counting defects fixed
  • Counting source control commits
  • Reviewing daily source control logs

For instance, here are the source control commits and defects fixed for an actual 6 person development team over about an 8 month period. Each developer has at least 10 years of experience and all have the titles of at least “Senior Software Engineer”.

This shows we have a big performance gap between our top and bottom
developers, but these two data points don’t tell the whole story: programmer B is a new hire and what separates programmers A, the NNPP, and C are the other red-flags listed above: missed estimates, high defect rates, naming conventions and re-inventing the wheel.


Once you have identified a NNPP, your goal should be to get as far away from them as possible. For better or worse, the team’s productivity and ability to meet deadlines and produce value for the business reflects on you. You should want to be part of a small, highly productive team that builds great software. You can’t do that with one or more NNPPs on your team. You can:

  • Fire them immediately
  • Give them a 30 day warning, then fire them
  • Find them a new role
  • Change jobs

Fire Immediately

If you are able and if your organization culture supports it, this is the best solution. Your team gets an immediate productivity boost and you get the opportunity to bring in a replacement that can be a net positive instead of a net negative. This is probably not possible in many large organizations or European countries, but for at will employment consider this your first option. If you are unable, or can’t bear to fire them, you’ll have to look at other options.

30 Day Warning

Similar to immediate termination, the 30 day warning gives the NNPP time to get their act in gear. If you’ve mis-read the situation or there are external factors that you haven’t considered, this gives the NNPP a chance to prove you wrong. This also gives the NNPP a chance to start looking for another job which may solve the problem without having to resort to termination, don’t count on it.

Find them a new role

Not everybody is cut out to be a programmer. Maybe the NNPP would be better off with a different role. You’ve already invested in hiring and training them, so they should at least be knowledgeable about your products, practices and culture. Maybe they would be a great QA engineer, a customer advocate, a sales engineer. Look around at the open positions in your company and see if there is something that might be a better fit. A tool such as StrengthsFinder might help them discover what they would be really good at instead of continuing to struggle with software.

Change jobs

If nothing else will work, you can always change jobs, internally or externally to get away from the NNPP and move to a place where you can be part of a highly productive team. There are no guarantees that you won’t be in the same situation or worse at your next position, but you should have an idea of what questions to ask to find a good team.


Of course, the best course of action is to avoid the NNPP in the first place.

If you are building a team, you want to hire smart people who get things done. This article isn’t about interviewing, but you must identify if they can:

  • Write a program
  • Understand code
  • Debug
  • Fix defects
  • Desk check their code
  • Learn new languages and skills easily

You can require code submissions and problem solving as part of the interview process, hire people you know, subject new hires to a 30 day trial period or use a variety of other interview techniques.

If you are coming into a new job, you probably won’t know if there is an NNPP on the team already. Chances are, you won’t interview with them, but you can do normal vetting and you always have the option to change jobs later or work from within to improve the team.


The Net Negative Producing Programmer is bad for you and bad for the business. While not everybody is a top performing programmer, we shouldn’t stand for the NNPP taking away from what we can accomplish. Do your best to avoid the NNPP as new hires and be on the looking for them on existing teams.


Burdened with technical debt

Incurring intentional technical debt should be a business-based decision. This doesn’t mean that business people need to be involved, but every time you make the decision to take the quick and dirty approach versus doing the right thing, there should be a solid reason behind it. That solid reason should be: this is better for the business. I know this sounds like something out of Office Space, but every time you copy and paste code, every time you don’t refactor, every time you violate a naming convention, every time you choose to leave a defect in the product, every time you write code without a test case, you should be doing it because it makes good business sense. At the end of the day, the software we write serves the business and is supposed to add to the bottom line.

Sometimes it makes sense to incur technical debt. Products can be shipped with defects and sometimes getting to market first or with a splash makes more sense than spending the time (read money) to get the architecture right and the code tight. If the business earns more money by first shipping a product, then addressing technical debt than it would by addressing the debt up front, it makes good business sense to incur that cost.

However, not all technical debt is intentional or considered in these terms. Teams under perform, make bad decisions, lack the required technical skills or just don’t care. The business may not even realize it is taking on this type of debt. The product may sell and perform well, but over time it will become burdened with so much accidental debt that it becomes bloated too hard to innovate.

What happens when a product becomes burdened with technical debt, intentional or accidental? From my point of view, just like being burdened with too much financial debt, there are no good choices or easy answers. You can:

  • Rewrite the software from scratch
  • Refactor and incrementally improve over time
  • Pay down your debt in a large chunk
  • Live with it
  • Find a new job

Scratch Rewrite

If you’ve got the time and the money, this might be a viable solution if you can sell it to the organization. You get to re-write the product with knowledge of already having a working system. However, it is expensive and at the end of what could be several years, you have a product that has the same functionality as your original code base, but with new and exciting bugs. In the mean time, you have to support the existing software and hope that the organization doesn’t decide to change course or scrap the re-write.

Refactor and incrementally improve over time

You can try and pay down your technical debt over time. Refactoring and code clean up should be something you do as part of your normal development process. It is a great way to understand and improve the code and reduce defects. But refactoring and code clean up is not a viable strategy for paying down large technical debts. First off, it reduces the team velocity towards new features that can actually be marketed and produce new revenue. Second, you may be solving the wrong problems: it may be hard to address architecture problems in the limited time and divided attention spans that will be in play when you are both innovating and refactoring. Finally, it just may not be feasible to pay down the debt by making the minimum payments. Consider that it takes 23 years and $7000 to pay down a $5000 credit card debt making the minimum payments each month.

Pay down your debt in a large chunk

Similar to a re-write, but instead of starting from scratch and building new software from the ground up, you could dedicate all or a large portion of the team to swarming and focusing on paying down technical debt for an intense, but fixed period of time. This could potentially reduce your technical debt to the point where you can again innovate and rapidly produce quality and important software. But, you’ll be spending a lot of money, you may not be successful in removing enough debt, and while you will have less technical debt, you won’t be free of it. Additionally, if your debt is fundamentally architectural, you may not be able solve the right problems with limited time and unless you fundamentally change your development practices after swarming you’ll only have delayed the problem.

Live with it

You could decide just to acknowledge and live with the technical debt. This is untenable in the long run and eventually you will spend most, if not all of your time, fixing defects instead of adding new value to the business. Innovation will be stymied and it will take more money, more people and more time to develop new features.

Find a new job

This may be the best personal decision. This is obviously not good for the business unless you are a NNPP, but if you enjoy designing and developing new software and creating value, them this might be right for you. Just make sure you learn from being burdened with too much technical debt and avoid the problem in the first place in your next job.