I recently asked this question on Stack Overflow. I was using reflection and MethodInfo to confirm that a controller contained an action with the required method parameters. If one was found, this would then allow my code to unit test that the correct Action Filter Attributes were being assigned to the controller action (so a particular action could only respond to an HTTP GET or POST as an example).
This was all working fantastically well but I made the mistake of trying a unit test too far and was surprised by the outcome. I was attempting to assert/validate the return type was of the desired type (e.g. ActionResult or JSONResult) but my assertion was failing. In the debug watch window I could see the return parameter was of the desired type but it was wrapped up inside a RuntimeType. No amount of fiddling/casting would get the test to pass. Another SO user helpfully pointed out that an MVC action might actually return RedirectToRouteResult, etc. so the wrapping was a requirement of the call – it was working as intended.
Thinking this through to its conclusion my original test was flawed, even if it was possible there is no need to test the return type of the reflected method info. Only when I am testing actual calls to the controller am I interested in what the returned type is and what it contains!
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 . . .