Continuous Disintegration

Sometimes doing the simplest things is difficult. In order to make any headway on SharpMock, I’ll need to be able to understand the basics of PostSharp. What could be more basic than getting PostSharp to execute a task that ouputs a ‘Hello World’ message during the postcompilation process? We’re not decorating any types with attributes; we’re not intercepting any calls; we’re not outputting any IL. This should be a snap! And yet, I haven’t posted in weeks…. First thing’s first – we need a ‘Hello World’ task. In a project called PostSharpPlugin I have defined the following class: using PostSharp.Extensibility; namespace PostSharpPlugin { public class SayHelloTask : Task { public override bool Execute() { Console.WriteLine( "Hello, PostCompiler!" ); // Task executed successfully return true ; } } } I have also created a .psplugin file that looks like this: <? xml version ="1.0"

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

I am a junior .NET developer currently working in Chicago, IL. I am starting this blog in order to enhance my knowledge of programming subject matter. Hopefully, someone else will be helped along the way. This first post will probably be edited soon...