Nerdy tidbits from my life as a software engineer

Friday, December 19, 2008

Mock State Machine Visualizer

I was debugging a unit test yesterday that was using my mock framework, when it occurred to me that it would be a lot easier to figure out where I was failing if could somehow visualize the state machine that my code was walking through.  Currently there’s no easy way to do this: you have to step through your code, find the place where you get an expectation violation, and then backtrack to your recording and determine where things don’t match up.  This is one of the big rubs against record / replay semantics, and understandably so.  But I am generally a believer in using ordered recordings, so it would be nice if there was a way to make it easier to compare an expected sequence of calls to the actual sequence of calls - visually.

So now I’m wondering, what is the best way to do that?  Throwing up a dialog on a failed call to Validate is probably a bad idea.  Unit Tests should never throw up modal windows.  Maybe I could write a log somewhere to disk which could then be loaded into a UI and seen visually?  That seems like an easy way to go.  I was thinking simple html would probably be an easy way to do this.  What would be really nice, of course, is if I could somehow integrate this with Visual Studio…but I don’t see myself having the time for that.

I want something that almost looks like a file diff.  The left side has expected calls, and the right side has actual calls.  Indentations can signal the bounds of nested ordered / unordered blocks.  Clicking on a line gives you the details about that comparison (such as whether the arguments were ignored, etc.).  It can’t be too hard to come up with something, don’t you think?

Wednesday, December 17, 2008

The Problem With The Chicken And Egg

Today I created a mock object in my framework whose constructor happens to call one of its own methods (just a property setter – no big deal – but it still calls it).  Before expectations can be set on the mock object instance, it must be instantiated, which means that the base class’ constructor is invoked.  However, because the mock hasn’t been created yet, there is no way to set an expectation on a method that the constructor is calling before it is created.  Which means that any object whose constructor invokes methods on itself is in a bit of a bind.  It can’t be created as things are right now without throwing an expectation violation.

One way to handle this problem is to use a partial mock instead of a regular mock.  This does solve the problem, since all of the method invocations pass down to the base class until you can set expectations on them.  But it made me wonder, should I put some funky code in the constructor code that I generate to handle this automatically?  I can’t remember what Rhino or Moq does, or what the expected behavior should be.  I suspect that they would barf, too…in which case, I’ll probably just imitate their implementation and keep my stuff behaving the same way.  But it does seem restrictive to either disallow methods to be called in the constructor of a class you want to mock, or to have no choice but use partial mocks for these situations.  Partials can be dangerous since they won’t catch cases where methods that shouldn’t be called are, in fact, called.

Tuesday, December 16, 2008

Overriding Dispose With Reflection.Emit

I ran into a bizarre problem today with my mock framework.  I was trying to create a mock on an object that implemented IDisposable, but I kept getting this strange error when I hit the CreateType method:

System.TypeLoadException: Declaration referenced in a method implementation cannot be a final method.

This didn’t make any sense to me, since I was in no way trying to override a method that was sealed – the Dispose method wasn’t declared virtual, but it wasn’t declared sealed either (besides, a method that implements an interface is virtual by definition).  Perplexed, I hit a breakpoint in the debugger and looked at the properties dialog to see if there was some obvious flag on Dispose’s MethodInfo that I should look out for in order to avoid this problem:


There’s nothing here that popped out at me.  The IsVirtual and IsAbstract values are true, and IsFinal is false.  What could possibly be wrong? So I started searching and came across this article on Microsoft support, which said something very interesting:

If this is done, no compile errors are raised. However, when the derived class is loaded at runtime, you receive a runtime error message similar to the following:

An unhandled exception of type 'System.TypeLoadException' occurred in

Additional information: Declaration referenced in a method implementation can not be a final method. Type: ClassLibrary1.UserControl1. Assembly: Dispose.

Although I’m still a bit perplexed as to what’s going on here, it appears to me as though the compiler is automagically making Dispose sealed by default on the implementer.  I figured this out be checking the MethodInfo on the class that implements the interface, not the interface itself (sure enough, it was final despite not being labeled as such in the code).  I’m not entirely sure why it’s doing this, but it is.  What I don’t understand is why this needs to be a runtime error.  Can’t this be caught at compile time?

We do a lot of funkiness with the Dispose method that I don’t particularly like.  I get the sense that this is another optimization having to do with IDisposable.  I hate making special cases for specific interfaces and classes.  I don’t have this problem mocking objects that implement other interfaces.  Why should IDisposable be any different?

Thursday, December 11, 2008

Introducing ‘Mimics’

With the coming release of .NET 4.0, I think we’re going to see the creation of a new type of unit testing object which I’ve decided to call a mimic.  A mock object requires polymorphism in order to work:


This requirement is due to the fact that without the help of virtual methods, there is no way to dynamically call another object that behaves like the Target unless it inherits from Target.  In most cases this isn’t a problem, but if Foo and Bar are not declared virtual, then you’re out of luck because the method pointer is determined at compile time instead of run time.  In those cases, there is no way to generate a Mock object and use it without altering some existing code.  Mock frameworks can’t work with these scenarios (unless they hijack the clr use the profiler API to dynamically insert different object types at runtime…see TypeMock).

But with the coming dynamics feature in .NET 4.0, you’ll be able to call Foo and Bar on instances of both Target and Mock, even if Mock is not a Target but behaves exactly the same way.  In other words, Mock is like a Target, but is not actually a target - it mimics the target.  The relationship looks like this:


I have a framework that I’ve been working on for the last couple months that has an implementation of a Mimic.  It’s not a difficult thing to do, I’m just really itching to see it work in action.  The breakthrough should make it a lot easier to unit test certain API’s (such as the WPF) that are currently very difficult to test because the vast majority of their methods are not virtual.

Wednesday, December 10, 2008

Private Set Instead of Readonly

Is there any reason you would rather declare

public readonly string SomeValue;

…instead of…

public string SomeValue
    private set;

From what I can see, in most cases, you’re better of having the private set (a 3.5 and above feature, admittedly).  Readonly certainly makes sense for constants, though my feeling is that you’re better of declaring those variables const instead of readonly in most of those cases.  In other words,

public readonly string SOME_STRING = "Some String";

is less preferable than:

public const string SOME_STRING = "Some String";

The reason being that any simple constant can be determined at compile time, whereas readonly values are determined at run time.  You can even give a quick scan to the IL produced by those two statements and see the difference yourself.  What you’ll see is that using readonly will cause the compiler to shove this into the IL of your constructor:

IL_0000:  ldarg.0
IL_0001:  ldstr      "Some String"

Where as using const will simply insert the assignment statement into the .field declaration:

.field public static literal string SOME_STRING = "Some String"

In other words, the first option will run for all instances of your class, whereas the second option will run when the object is loaded onto the heap (it also allows you to access the value of fields using reflection, which has other uses).  So, why use readonly at all?  Well, you can’t do this using const:

public const Object SOME_OBJECT = new Object();

Because consts can’t be instance objects.  This is really why we have the readonly keyword, because it lets you do this:

public readonly Object SOME_OBJECT = new Object();

Which does admittedly have some value.  But the problem with this code is that you’re exposing public member variables instead of public properties.  This really is a cardinal sin, in my opinion, because you are explicitly giving up one of the most important features of object orientated programming: encapsulation.  Properties allow you to get the convenient syntax you’re looking for without sacrificing the benefits of abstraction.  If you ever wanted to refactor your code so that SOME_OBJECT did some sort of funky logic, or if you ever started adding subclasses and create a hierarchy, you’d be stuck because you chose to make SOME_OBJECT a public member variable instead of a property with a private set.

I see plenty of value in having private readonly variables – but anything that is exposed to the rest of the world should really be encapsulated in a property.  Otherwise, make it const.

UPDATE: It’s occurred to me that there is one useful place to use readonly, and that is when declaring static readonly fields.  This actually can make life a little bit easier, because doing it using properties would usually require quite a bit of extra code to just about the same thing.  You could easily author a few static properties, add a static constructor, and accomplish more or less the same thing that happens when you declare a static readonly field.  Of course, you’re still accessing the value via a public field, which I think is less preferable to a public property.  But as long as it’s readonly, I don’t think you’re really violating any terrible design principles.

Tuesday, December 9, 2008

How Many Auto Update Programs Do We Need?

Do we really need so many startup, taskbar sitting executables constantly checking to see if our software is out of date?  Just off the top of my head, each of the following commonly used applications installs some sort of auto-update manager:

  • Adobe Acrobat
  • Flash Player
  • The Java runtime
  • iTunes
  • Quicktime
  • Windows Update

I understand the need to keep everybody’s machine up-to-date with the latest version, but can’t we just agree on a standard system instead of having to go through hoops to kill these update managers one by one?  I wonder if they’re baking this into Windows 7…that would be a very welcome addition.  Nothing angers me more than booting up to see 3 dialogs from Adobe, Apple and Sun pestering me to update my software.  Leave me alone already!