Skip to main content

Whatever Happened to Pong ... err ... SharpMock?

Just short of four years ago, I came up with an idea for replacing static/sealed methods in legacy code (the Michael Feathers kind) with fakes for testing purposes. Here's a quick rundown of what happened after I had that idea:

  1. Messed my brain up trying, for several hours over the course of many days, to figure out how to bend PostSharp to my will
  2. Left it alone for months
  3. Came back to it and spent several hours re-learning what I needed to know
  4. Left it alone for months
  5. Came back to it again and spent several hours re-learning what I needed to know
  6. Left it alone for months
  7. Came back to it and decided to try using LinFu as the AOP framework driving things
  8. Had what seemed like a pretty decent prototype working based on a dozen or so unit tests that fell apart under a little more weight
  9. Gave up on LinFu and left it alone for a few months
  10. Started over using Microsoft CCI Code Model to create my own specialized AOP framework to drive the mocking framework
  11. Made minor advances
  12. Left it alone for months
  13. Made minor advances
  14. Left it alone for months
  15. Paddle the paddle to the side to the side, To the side to the side to the paddle the paddle
  16. ...
  17. Finally started getting a bit more serious, found a decent development workflow, and started banging out some features

So that's where things stand now - there's repo over on GitHub with some really horrendous code in it that passes a handful of tests while being pretty much unusable in real-world scenarios.

For the most part I'm having fun with it and just trying to get it into a somewhat stable state. (I'd like to say it's always fun, but it's actually not, probably because I'm doing something wrong. I'll try to explore that in a later post.) Once I get the 'basic' features implemented, along with one or two other critical usability pieces, I'll starting publicizing it in an attempt to get people to use it. A main test for me is getting it to work on a few libraries in the codebase at my current job - and even for the implemented features, it does not.

But I Need to Fake Static Methods!

You have plenty of options:

  • Functionally, far and away the best option is TypeMock
  • TypeMock has a competitor
  • I'm pretty sure support for this free alternative will be baked into VS 2012
  • Pretty soon all the cool kids will be doing this; at that point in time, I'll hang my head in dismay for having spent too much time ponging around
Labels:

Comments

Post a Comment

Popular posts from this blog

Who I'm Is

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...
Post a Comment
Read more

Stubbing Static Methods with PostSharp

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...
6 comments
Read more

Strongly-Typed Property Constraints in Rhino Mocks

UPDATE: As I suspected, this functionality was right in front of my face – it’s called PredicateConstraint in Rhino Mocks. I also realize that I managed to completely ignore the existence of Predicate<T> in the framework, and write my own predicate delegate. Hey, I was on a roll. Rhino Mocks has a PropertyConstraint class that allows you to check the values on properties of objects passed into the method as part of the verification for that method being called. Unfortunately, the name of the property is specified as a string, which means the benefits of strong-typing that Rhino Mocks is normally so good at preserving are lost. Here’s an example (using Rhino Mocks 3.3 and .NET 2.0): [Test] public void Main_Form_Should_Show_Start_Panel_On_Load() { MockRepository mockRepository = new MockRepository(); IMainFormView mockView = mockRepository.DynamicMock<IMainFormView>(); IEventRaiser loadEventRaiser = GetEventRaiserFor(delegate { mockView.Load += null; });...
Post a Comment
Read more