Continuous Disintegration

The first time I popped open the solution after I did my ‘SharpMock’ spike, I was met with a surprise – the one test was failing! Surely I didn’t commit a cardinal sin and write a post about something that didn’t even work. It turns out I had been messing around with the OnMethodInvocationAspectOptions returned by overriding the GetOptions method of OnMethodInvocationAspect . Here’s the code that was in MockableAttribute : public override OnMethodInvocationAspectOptions GetOptions() { return OnMethodInvocationAspectOptions.WeaveSiteCall; } The original incarnation of Expect.Call(….) took a string to specify which method on which class to call, so the test passed with the above code. Now we have this syntax: Expect.Call(() => PersonDao.GetPerson(0), ryan); And the test doesn't pass. This means that if we want to have syntax like this (and we do!), we have to do the weaving in the class we’re calling. Much more importantly, if we want to preserve this syntax and not modif

I figured the first hurdle to tackle in proving that we can use PostSharp to bend assemblies to our unit testing wills was to get rid of the need to decorate the targets of our mocking desires with attributes. I spent some time going over the documentation , browsing the forums , and looking through samples. Gael pretty much told me in the comments to my previous post to look into ICustomAttributeProvider and CompoundAttribute . I tried and failed to implement ICustomAttributeProvider; I think I don't quite understand how a PS plugin works yet. I thought going through Ruurd Boeke's examples would be enlightening... no such luck. So, instead of doing the smart thing and actually asking for help, I'm going to continue to waste time trying to figure it out on my own. Eventually I'll get fed up and ask for some help, but in the meantime I need to make some progress somewhere in this experiment. I might as well take what I have done and at least build out some real func

TypeMock uses the Profiler API to allow mocking, stubbing, etc. of classes used by code under test. It has the ability to handle sealed classes, static classes, non-virtual methods, and other troublesome-yet-oft-encountered scenarios in the world of unit testing. Other frameworks rely on proxies to intercept method calls, limiting them to be able to only fake virtual, abstract, and interface members. They also rely on dependecy injection to place the proxies as the concrete implementation of calls to the abstracted interface members. Anyone working with a legacy codebase is bound to run into static method calls (especially in the data access layer), dependencies on concrete types with non-virtual methods, and sealed class dependencies (HttpContext anyone?). The only way to unit test this without refactoring is with TypeMock. I've never used TypeMock, and I'm sure it's a great product, but it's not free. I decided to spike some code to see if I could solve the prob