An Observation on The Human Condition

…thus Refactor, Test Driven Design, and Agile.

Or, “success is the ability to change”.

StirTrek ASP.Net MVC2 Demo

Thanks to everyone who came to my presentation at StirTrek.  The demo code can be found on my account on BitBucket. (Check out the “get source” link in the upper right hand corner to download a zip.)

Links from the talk:

MVCContrib - http://mvccontrib.codeplex.com/

MVC Futures Library - http://aspnet.codeplex.com/releases/view/41742 (Included in the MVC2 source release)

MVC2 in Action download - http://jeffreypalermo.com/blog/read-all-of-asp-net-mvc-2-in-action-now-while-you-wait-for-the-printed-book/

How To Test ASP.Net MVC JsonResult

Testing the result of an ASP.Net MVC controller action that returns an anonymous type can be difficult. This task is made difficult by the fact that the framework serializes the return value under the covers before it gets returned to the client.

On the unit test side, I don’t have anything to cast that anonymous type to so I can get at it’s contents.

The best and most simple way (so far) that I’ve found to accomplish this goal is to use a class from the System.Web.Extensions DLL called System.Web.Script.Serialization.JavaScriptSerializer.

Here’s a simple test to demonstrate:

Please let me know if you know of a better way to perform this verification.

Making Tests More Readable with Fluent Assert

Last week I discovered the Fluent Assert project. It allows me to write tests that even humans can read:

Now, isn’t your mouth watering for some fantastically readable .Net BDD tests?

I like this style because my previous attempts at making unit tests readable has always seemed like somewhat of a failure. Using this framework there is really no room for readability or design error.

What you end up with is very short, terse, well documented methods that do one thing. That sounds very clean code-like! ...and it is.

This framework drives me to a good unit test fixture design in the same way my unit tests drive me to a good production code design.

Another important note about this framework: it is extremely simplistic. The framework really does nothing more than take the test methods that you write and give you a nice fluent syntax.

Added Goodness

All of the short methods and good naming that this framework leads you to gives you a lot of re-usability. Consider the test that I write to ensure that the pie is not done when it’s been baking for only 30 minutes:

All of my previous setup and arrangement can be re-used without having to use inheritance or any other tricks to keep my code as readable as possible.

Minor Nit

There is duplication going on with my naming. I already write my fixture class name and unit test methods with the BDD style, and now I’m repeating myself with this fluent syntax. Example:

Perhaps this is less of a problem with the Fluent Assert framework and more a problem with the C# language!

A Dive Into Distributed Source Control

My team has recently made the switch from Visual Source Safe to Mercurial.  Here are some noteworthy points about this adventure:

Ability to be choosey about when to release your code

How often has this happened to your team: the source builds, and all the tests pass, so you commit your changes at the end of the day.  The next morning you’re running a little behind, and you’re greeted with the stink-eye by your colleagues.  You only half way implemented the log-in page so everyone is locked out of the application…until you fix it.  With distributed source control this problem goes away. 

Using distributed source control I can commit locally any time I want without affecting the rest of the team.  Meanwhile, I still get the ability to punt and rollback changes if and when I get too far down the wrong path. 

A nice side effect of a clean shared repository is that it’s ship-able at almost any time.

Effortless reverts/rollbacks

As soon as I’ve completed a decent chunk of work (a passing unit test or a layout change) I commit.  Commits happen in the blink of an eye, so there’s no disruption to my workflow.  Also, every time I check work in, I tag it with a 4-6 word description of what I just did.  Now I have a really nice trail of comments to show me where I’ve been.

Since the change sets are small, those commit comments become much more meaningful.  Other developers can look through the change log and pick out interesting looking changes to learn from.

Since the repository is on a local disk, reverting or rolling back changes takes one or two seconds.  Because of the speed and frictionless experience, it makes you feel much freer about using the features.  Subversion/TFS/et. al. all have the ability to revert, but it’s a process and ceremony that takes so much time that I’d rather work around it.

Safety

If you’re using distributed source control the way it was intended (small commits, pushed to a shared repository) there is almost no way to lose code.  The biggest feeling of safety I get over using traditional SCM’s is when I’m merging.  Using Subversion or TFS, if I goof a merge then my working copy is in a broken state until I rectify it.  If I’m using a distributed system and I fat finger a merge, I’m just a revert command and one second away from my pre-merged code.  After my revert I can take a deep breath and try that merge again.

Easy branching/merging

This is the one thing that everyone talks about, and it is true.  Branching and merging is effortless once you’ve unlearned what subversion and other central-control systems have taught you about it.  I found www.hginit.com to be a great way to understand the essence of distributed source control usage.

Easy integration with TeamCity

For the first time in my career, I am the guy in charge of the continuous integration server.  I was a bit daunted at the task, but TeamCity made it simple.  TeamCity’s support of Mercurial is first class and makes it simple to pull the code and build it.

GUI Tools for learning

When I first started getting a feel for distributed source control I leaned heavily on TortoiseHG.  It was a great way to visualize branching/merging and some of the other new concepts that I needed to learn.  Now that I’m a little more seasoned, I get a lot less workflow fiction by relying on the CLI.

VisualHG is a Visual Studio plugin that is a lot of help.  The primary interest I have in VisualHG is that it tracks all of the actions I take in the IDE such as adds/removes/and renames.  These actions otherwise require me to remember to make Mercurial aware of the action by using the ‘addremove’ command. 

Corrupted my repository

One word of caution: do not inadvertently touch the local repository files.  TortoiseHG by default makes copies of files that you revert.  I hadn’t noticed this until later, so I wanted to clean up all of those un-needed files.  By doing a search on the parent folder of my repository I found _all_ of those files and deleted them – including the ones that were in the repository.  Dumb.  Mercurial was very kind and told me there was a problem – and what revision I could revert back to.  To get out of that pickle, I pulled the latest version of the shared repository and merged my working copy into that.  I lost a few changesets from my local repository – but all my code was still safe from my working copy. 

Why Mercurial over Git?

A couple reasons, most of which are based on gut feel.

1) Git commands seem esoteric compared to Mercurial.  Mercurial’s commands just feel natural and like something I can easily remember.

2) Everyone raved about Mercurials Windows support, along with excellent GUI tools.  Meanwhile I heard only bad things about Git’s Windows support.

3) Codeplex began to support Mercurial, so there was an extra confidence push that raised the comfort level.

4) Martin Fowler’s article on source control management tools didn’t hurt.

5) I have to worry about line endings?  This was actually a big turn-off.

6) Git has a strong community following, but after poking around for Mercurial resources I found solid community backing there as well.

Conclusion: What you’ve been told is true, distributed source control systems are a much more natural fit than traditional SCMs.  It’s really quite difficult to explain the feeling of freedom I get when using source control that I feel works with me…but just trust me: it’s a good thing.

Comparing and Contrasting Moq and Rhino Mocks

My friend Jon is starting a training course in an effort to quickly bring developers up to speed on test driven development. As part of this effort, he has developed a unit test suite aimed at helping folks understand Rhino Mocks, a popular testing tool. After looking through the tests and seeing a lot of the Rhino API that I wasn’t familiar with, I wondered if there were similar undiscovered nooks in my favorite mocking framework: Moq.

After getting permission, I took his tests that use Rhino Mocks and implemented them with Moq. It was a great exercise for not only learning the two APIs, but also for getting a side by side comparison of the frameworks. The differences in most cases are subtle, and ultimately I found the choice between each to be a matter of taste.

You can find Jon’s tests here, and mine here.

Points of Interest

Mocks & Stubs?

I’m in agreement with Jon that the differences between mocks and stubs are mostly semantic, and are best reserved for academic discussions. I called all the variables in my tests “mock” because the class for creating mocks and stubs with Moq is “Mock”.

API Surface

The reason I am such a fan of Moq is that the API “surface” is minimalistic. The methods I want to use most often are within clear sight and meaningful. There’s not a lot of extra jargon and noise that I have to think about. The methods that I use 20% of the time are tucked away in a manner that is still discoverable, but yet hidden enough to give me a signal that they’re not the first path I should choose.

When I want to create a mock with Moq I have one choice:

With Rhino I have several choices:

The more decisions I’m forced to make, the more disruptive the API becomes.

Jargon Watch & API Clarity

A few examples of pros/cons of the APIs

Creating a mock of a concrete class with virtual methods
…in Rhino Mocks:

In Moq:

The simplicity of Moq’s API shines. (Replay?*)

*Replay is a concept that was prevalent in prior versions of Rhino Mocks and it continues to necessitate appearances. The record/replay syntax is still available for backward compatibility, which adds to the verbosity of the API. Read more about record/replay.

Finding the arguments passed to a stubbed method
…in Rhino Mocks:

In Moq:

I prefer the Rhino syntax in this case. The concept of a “callback” is clear enough, but it is not clear that I should be using it to perform checks on passed arguments.

Feature Parity

There are some features that are exclusive to the current versions of the libraries:

Ref Arguments

Rhino Mocks provides full support for methods with Ref arguments. Moq does not seem to. (I have an ignored failing test in my code. If you know how to make it pass please let me know!)

Mocking Protected Methods

Moq provides built-in support for mocking protected methods. You can still test protected methods with Rhino mocks, but you’ll have to write some reflection code to do so.

Conclusion

I favor the style and feel of the Moq API for some of the reasons described above, but as they say: “To each his own!” Hopefully you’ll find the side by side comparison helpful in determining your preferred mocking framework.

Have I missed anything? Please let me know if I’ve misrepresented or missed critical information that would help to clarify this comparison.

Another Industry Coping with Wicked Problems

Software development is full of wicked problems:

“[A wicked problem is] a problem that is difficult or impossible to solve because of incomplete, contradictory, and changing requirements that are often difficult to recognize. Moreover, because of complex interdependencies, the effort to solve one aspect of a wicked problem may reveal or create other problems.” (http://en.wikipedia.org/wiki/Wicked_problem)

So I began to ask myself how other industries handle wicked problems. The root of the problem is uncertainty. It’s hard (impossible?) to be certain that the designs we’re generating are going to produce an elegant solution. One example I found was the healthcare industry. Here’s one coping strategy:

“If we are uncertain about the relative intrinsic merits of any [different]
treatments, then we cannot be certain about those merits in any given use
of one of them – as in treating an individual patient. So it seems irrational
and unethical to insist one way or another before completion of a suitable
trial. Thus the answer to the question, ‘What is the best treatment for the
patient?’ is: ‘The trial’. The trial is the treatment. Is this experimentation?
Yes. But all we mean by that is choice under uncertainty, plus data
collection. Does it matter that the choice is ‘random’? Logically, no. After
all, what better mechanism is there for choice under uncertainty?”

Ashcroft R. Giving medicine a fair trial. British Medical Journal 2000;320:1686.

This author’s antidote to uncertainty in medicine? Learning, trial, and experimentation.

We need to test the viability of the new ideas we come up with so we can choose the best one. If only there were only some way to apply this practice to software development!