To fully test an MVC web site it is important to test (in isolation) the following:
- The behaviour of controller actions
- The behaviour of any custom action filters.
- The decoration of action filter attributes on controller actions.
To test the 3rd point, you must use reflection to select the desired action from the controller. The following method takes an action name and a Tuple array of “Type” and “String”. Used together this combination should be enough to isolate the desired action. Note: an empty tuple array is used to define no input parameters, which a null tuple array specifies that this shouldn’t be used to restrict the action (in this case the action name must be null)
public MethodInfo SelectAction(Controller controller, string actionName, Tuple[] expectedParameters = null) { var methods = controller.GetType().GetMethods(BindingFlags.Public | BindingFlags.Instance).Where(mi => mi.Name.Equals(actionName)); if (expectedParameters != null) { methods = methods.Where(mi => CompareParameters(mi.GetParameters(), expectedParameters)); } if (methods.Count() == 1) { return methods.First(); } var ex = new Exception((methods.Count() == 0) ? "No matching actions could be found on controller" : "More than one matching action could be found on controller"); ex.Data.Add("Controller", controller.GetType()); ex.Data.Add("Action", actionName); if (expectedParameters != null) { var parameterList = new StringBuilder(); foreach (var expectedParameter in expectedParameters) { if (parameterList.Length > 0) { parameterList.Append(", "); } parameterList.AppendFormat("{0} {1}", expectedParameter.Item1.Name, expectedParameter.Item2); } ex.Data.Add("ParameterList", string.Format("({0}", parameterList.ToString())); } ex.Data.Add("Matching Actions", methods.Count()); throw ex; }
This can then be called using the simple format below. This code confirms that the controller has two search actions. One taking no input parameters, whilst the other takes a bound input model.
public MethodInfo SelectAction(Controller controller, string actionName, Tuple[] expectedParameters = null) { MethodInfo action = null; Assert.DoesNotThrow(() => action = SelectAction(new CustomerController((new MockHttpContext()).Object), "Search", new Tuple[] { })); Assert.That(action.Name, Is.EqualTo("Search")); Assert.DoesNotThrow(() => action = SelectAction(new CustomerController((new MockHttpContext()).Object), "Search", new[] { new Tuple(typeof(CustomerSearchInputModel), "inputModel") })); Assert.That(action.Name, Is.EqualTo("Search")); }
In the next post, I will cover how to use this to assert the decoration of action filter attributes.
Today I realised that I’d forgotten how spoilt I am using Resharper and dotCover to run my unit tests. Put another way I’d forgotten how badly Visual Studio plays with any other unit test frameworks other than MS Test! I’m used to and really like the fluent API style of NUnit’s Assert.That(…) syntax so having to fall back to MS Test always feels like a step back. If you ever find yourself in a situation . . .
When I first started looking into Windows Workflow one of the first things that I liked about it was how it separated responsibilities. The workflow was responsible for handling the procedural logic with all its conditional statements, etc. Whilst individual code activities could be written to handle the business logic processing; created in small easily re-usable components. To try and realise my original perception this series of blog posts will cover the unit testing of . . .
Something like that allows you to assert the decoration of an action filter on a Controller:
Type t = typeof(SomeController);
Assert.IsTrue(t.GetCustomAttributes(typeof(SomeController), false).Length > 0);
@Julien, Thanks – you've reminded me that I must finish and publish the post on asserting the decoration of action filters – hopefully get something done over the weekend.