Mehfuz's WebLog

Mocking .net framework members (a.k.a. mscorlib) is always a daunting task. It’s the breed of static and final methods and full of surprises. Technically intercepting mscorlib members is completely different from other class libraries. This is the reason it is dealt differently. Generally, I prefer writing a wrapper around an mscorlib member (Ex. File.Delete(“abc.txt”)) and expose it via interface but that is not always an easy task if you already have years old codebase.

This will post will show how you can use AutoBox to easily write a bootstrapper for ASP.NET MVC. I have used the latest version of AutoBox (available from nuget, this version also includes Castle.Windsor internally for managing dependencies rather using its own resolver and does not require interface to type naming convention [IAccountRepository –> AccountRepository]) . To understand what is AutoBox , how you can use it for caching using memcached and let it automatically handle dependencies for controllers and repositories, i would recommend to take a look at this post:

How you assert through unit test that an user is authenticated before doing withdraw operation? You can surely verify a method is invoked as expected but if you want to ensure the order right then you might require a little more. JustMock lets you specify the order in which your setups should be executed. This helps you identify the exact way in which a particular logic is implemented.

When asserting an expected call for its number of occurrences or may be just to verify if the setup/arrange is acted as intended, the tool generally raises assertion that points us to the reason why the test failed. Different mocking tools use different exception classes therefore there is no common way to consolidate them.

In my previous post, i showed how JustMock picks mock expectations based on current context without the instance being injected. Based on feedback we found that It’s sometimes confusing and often does not work as intended. However, the context of this post is not to introduce future mocking rather a new feature that allows you to skip mock instance intentionally (when you can’t pass the dependency through a constructor or via method argument) instead the tool is applying it for you on behalf.

Just when we have dependencies for a controller, we need to wrap around our heads to write a bootstrapper that will dynamically inject dependencies for a controller in runtime and once we we want to do  data caching like a particular method in accounts repository need to get cached for a  certain number of time and it should invalidate when someone calls update, things get complex and may be we get around this with some attribute based solution.

Previously , I have posted how it is possible to mock a method without passing the dependency through a constructor / calling method. This is something true for third party controls and tools where we have little control over how its created.

In this post I will show mocking a member call inside a PostSharp aspect. There were previously compatibility issues between both of the tools running side by side which is now been officially fixed with the most recent release of that tool (>= 2.1.2.8-1594). For those who don’t know what PostSharp is all about, it is a tool that lets you write aspects easily than you can imagine.