Friday, February 15, 2008


Roy today proposed an Abstract Expectatations and Isolation Syntax.

It sounds pretty interesting but I'm worried it might gloss over some of the valuable differentiating factors among mock object frameworks.

Union or Intersection

Ultimately its success will depend on whether AEIS takes a union or intersection approach to its API design.

Union: AEIS tries to support everything all of the frameworks can do.  The downside is that the user loses the built-in constraints that indicate when a framework cannot do something in particular.  It's unclear what would happen if one attempted to use unsupported constructs within a test.

Intersection: AEIS only supports common features among all frameworks.  The downside is that the user can no longer access certain fancy/more powerful capabilities only offered by one framework or another.

With and end-user facing API like AEIS, I am somewhat concerned about limiting the ability of mock object framework providers to innovate with respect to syntax and expressive power.

However... Roy may yet be able to pull this off!

It's hard to sell an abstract product

Differentiation in an abstract API is difficult because the abstraction limits the range of capabilities that can be exposed.

For this reason, I tend to pursue abstraction behind the scenes rather than at the surface.  Users may not get as much front-end unification but instead they receive an effective set of concrete APIs that nevertheless take advantage of unification of back-end services.

For example, all mock object frameworks would benefit from common execution and reporting hooks.  Likewise, they may benefit from a common constraint framework.  The expectation syntax can be somewhat unified among record/playback tools, but eventually we reach a point where abstraction produces diminishing returns and each framework will need to go its own way.

So I believe that for AEIS to take off, it will need to know when to step out of the way and allow the individual frameworks to express their concrete nature in the fullest.

Saturday, February 9, 2008

View the source right inside the test runner!

I've been super busy lately getting MbUnit v3 and Gallio ready for another release.  But I'm not the only one...

Icarus Affordances

Graham Hay has been working his magic on Icarus, the Gallio test runner GUI.  Recently he added the View source code feature.

Select a test in the test tree then right-click View source code:

And here is the Icarus code viewer tab with the cursor automatically placed on the first line of the test method:

Affordances Galore

Source information is also used in other places.

The command-line test runner, MSBuild, NAnt and PowerShell tasks also display source code location information as part of the test results.

The source code location is included in XML reports, of course.  However, I'm still not sure how to effectively present this information in an HTML report.  Any ideas?

The ReSharper test runner also supports jumping directly to the code from the Unit Test Explorer view.  (This feature uses a slightly different mechanism that does not require PDBs.)

Fun stuff!

Thursday, February 7, 2008


I went to bed last night with code on my mind wondering how long it would take to get about 20 failing tests fixed.

I didn't sleep very well...

When I woke up I found that my wife had written the following on the whiteboard in my home office:

"A sphere..."
"A sphere is not a cube!"
Jeff talks GEOMETRY in his sleep.  2/7

I didn't know I did that.  I think it's time for a vacation.