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 . . .
It seems that a common aim when first starting out in unit testing is to obtain 100% code coverage with our unit tests. This single metric is the defining goal and once obtained a new piece of functionality is targeted. After all, if you have 100% code coverage you can’t get better than that, can you? It’s probably fair to say that it’s taken me several years and a few failed attempts at test-driven development . . .
By default objects mocked using MOQ will handle calls to method/properties that have not been defined, which 99% of the time will be the desired behaviour. Occasionally however a situation will require that MOQ throws an exception when accessing an undefined method or property. The MOQ framework provides this functionality via the MockBehavior enum but this can only be set during the construction of the mocked object. Typically this won’t cause any problems as the . . .
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 . . .
It is a shame that when the ASP.NET MVC framework was released they did not think to build IoC support into the infrastructure. All the major components of the MVC engine appear to magically inherit instances of HttpContext and it’s related objects – which can cause no end of problems if you are trying to utilise Unit Testing and IoC. Reading around various articles on the subject just to get around this one problem requires . . .
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 . . .
Update – 14th February 2016:Looking in my blog stats, this continues to be one of my most popular articles, so it is most definitely worth an update. As of v4.2.0 Automapper has been updated to remove the static implementation. I’ve not had chance to play with the new version yet but I would imagine this version will now work with any IoC container you wish to use it with. Original Article:The main “Mapper” class of . . .
When unit testing ASP.NET MVC2 projects the issue of injecting HttpContext is quickly encountered. There seem to be many different ways/recommendations for mocking HttpContextBase to improve the testability of controllers and their actions. My investigations into that will probably be a separate blog post in the near future but for now, I want to cover something that had me stuck for longer than it probably should have. That is how to mock non-abstract/interfaced classes within . . .
Today I read Roy Osherove’s blog post “Two Different ways to create bad logic in unit tests“. It’s an interesting article that covers logic included in many unit tests, is it acceptable to compare a returned string value using a comparison value built via string concatenation? It is perfectly possible that an issue introduced by the concatenation process is duplicated in both the code and the unit test – more often than not the logic . . .