Somehow I managed to find myself reading a very long rant on RoR and the RoR community by Zed, the creator of Mongrel.  He picks on lots of people, groups of people, technologies, and companies, but here's some of my favorite parts from his rant.

This is exactly what makes Rails a ghetto. A bunch of half-trained former PHP morons who never bother to sit down and really learn the computer science they were too good to study in college.

You hear that? The #1 money maker for 2008 years will be Rails cleanup. I’m not shitting you, it’s true and so just get over it and make the money.

If anyone had known Rails was that unstable they would have laughed in his face. Think about it further, this means that the creator of Rails in his flagship products could not keep them running for longer than 4 minutes on average. Repeat that to yourself. “He couldn’t keep his own servers running for longer than 4 minutes on average.” Assuming his statements are true (which we may never know) he basically duped us all.

What pisses me off is that I know they’re responsible (ThoughtWorks) for turning Ruby on Rails into the next Visual Basic.

After ThoughtWorks left the most recent project we revamped the team. We got rid of pair programming, cut down the number of tests, started cleaning more and more code out, got rid of their shitty tools, and we all started leaving at 6pm. What happens? We doubled our productivity with fewer people.

First it started on the fringe in start-ups and a few lonely places where it’s having mixed success (mostly due to the poor performance of the Ruby platform). Now it’s getting adopted internally at companies where of course it’ll get fucked up again and die off. After that it’ll move to the government sector where it will languish along with it’s new found buddy COBOL.

One of the topics brought up at the agile beer night was test fragility and how mocking frameworks can be a contributor to test smell.  Actually, I'm the one who brought up the point about mocking frameworks and fragility, but further examination revealed some disparity on the subject, specifically related to replay semantics.

I know that when I first started using a mocking framework I assumed it was best practice to use strict mocks.  I mean, why wouldn't you want to verify everything possible?  Apparently I'm not the only one to think this at one point or another.  I found this blog post by Derik Whittaker stating how he prefers strict mocks, it gets really interesting once you read through the comments.  Scott Bellware made the following comment:

Strict mocks is often a design smell.  It causes tests to express knowledge of an operation's internals, which is a violation of encapsulation of the system under test.

Any large code base that depends on strict mocking by default will suffer from unnecessary productivity loss due to breaking tests that have to be fixed where those tests suffer from inappropriate intimacy.

An API's internals are supposed to be allowed to change independently of its tests.  This is an essential quality of an agile codebase.

Strict mocking by default is a rather extreme stance.  Agile succeeds by finding those places where strictness can be slackened without causing any observable and categorical loss in integrity.  Opting for the strictest possible default runs contrary to this heuristic.

Through years of experience with mocking frameworks have I come to the realization that loose mocks should be your default.  Apparently the creator of Rhino Mocks, Ayende, agrees (emphasis is mine).

As an aside, I am deprecating CreateMock in favor of StrictMock. Using strict mocks by default was a bad design decision on my part.

One of the primary reasons mocks introduce fragility is that they require knowledge of the SUT that goes deeper than the public API.  You often need to know what methods on a collaborator will get called and setup some sensible return values that force your SUT through a particular branch of code. To me that's the very definition of tightly coupled.

So, how do we take advantage of a mocking framework, without making our tests fragile and resistive to change?  Unfortunately there's no way to completely avoid the mock object tax, but we can certainly minimize it.

One of the very first things we can do is setup our mocks in a shared fixture setup method. Sharing mock setup between tests is a great way to reduce the verbosity of each test.  A shared setup method will also setup the SUT with the appropriate mocks.

[SetUp]
public void SetUp()
{
    mocks = new MockRepository();
    userRepository = mocks.DynamicMock<IUserRepository>();
    purchaseService = mocks.DynamicMock<IPurchaseService>();
    sut = new Controller(userRepository, purchaseService);
}

You'll notice that the shared fixture setup I've created is using Rhino Mocks dynamic mocks.  You could instead use an auto mocking container to create the mocks for you to save some keystrokes and repetition.

With loose replay semantics (dynamic mocks in Rhino terminology) any method call during the replay state is accepted and if there is no special handling setup for this method a null or zero is returned. All the expected methods must be called if the object is to pass verification.

Too many times I've been burned by an over specified test using strict mocks.  With strict replay semantics only the methods that were explicitly recorded are accepted as valid. This means that any call that is not expected would cause an exception and fail the test. All the expected methods must be called if the object is to pass verification.  Depending on the mock this could be rather verbose leading to many expectations that have nothing to do with the actual test.

Tests should test only one thing.  You may have multiple assertions or expectations per test, but all of those assertions should have the same goal or theme.  I only want to setup the minimal amount of expectations on a mock that will verify a particular behavior in my SUT, anything more is over specified.  More to the point, keep your tests short and concise.

By using dynamic mocks rather than strict mocks, we are free to ignore the parts of the interaction between the SUT and the mock that we don't care about for our particular test.  We can also use setup result instead of expect if we can verify the interaction using a classicist approach.

[Test]
public void Should_show_cart_empty_message_if_cart_is_empty()
{
    SetupResult.For(purchaseService.GetCart()).Return(new ShoppingCart());
    mocks.ReplayAll();

    sut.ShowCart();

    Assert.AreEqual("You're shopping cart is empty", sut.Flash["warning"]);
}

Here I'm verifying behavior without explicit help of the mock framework, I'm only using the mocking framework to stub in my external dependencies and then verifying the expected behavior using a traditional assertion. 

If it weren't for the external service dependency I probably wouldn't be using a mocking framework here.  Mocking frameworks are most valuable at the edges of your components where things come together with the SUT, like databases, web services, and files.

The normal flow through the controller actually uses the purchase service for more than just grabbing the cart, it also uses it to grab the customer's billing information, but for this particular test I don't care whether the billing details get populated or not.  Here's the simple controller method we're testing:

public void ShowCart()
{
    PropertyBag["customer"] = userRepository.GetCustomerDetails(userID);
    PropertyBag["billing"] = purchaseService.GetBillingInfo(userID);

    ShoppingCart cart = purchaseService.GetCart();
    if (cart.IsEmpty)
    {
        Flash["warning"] = "You're shopping cart is empty";
    }
}

Lets say I now want to verify that the billing information gets populated when ShowCart is called.  Here the tables are turned, I don't really care about the call to GetCart() on the purchaseService.  I really only care that the property bag gets properly populated with billing information.

[Test]
public void Should_show_billing_info()
{
    SetupResult.For(purchaseService.GetBillingInfo(0))
        .IgnoreArguments()
        .Return(new BillingInfo());

    mocks.ReplayAll();

    sut.ShowCart();

    Assert.IsNotNull(sut.PropertyBag["billing"]);
    Assert.IsInstanceOfType(typeof(BillingInfo), sut.PropertyBag["billing"]);
}

Perhaps now we're concerned with populating the correct billing information, because as you might imagine, showing someone else's billing info would be a horrible security flaw.  So lets change our test to verify that using a mock.

[Test]
public void Should_show_billing_info()
{
    sut.CurrentUserID = 5;
    Expect.Call(purchaseService.GetBillingInfo(5))
        .Return(new BillingInfo());

    mocks.ReplayAll();

    sut.ShowCart();

    Assert.IsNotNull(sut.PropertyBag["billing"]);
    Assert.IsInstanceOfType(typeof(BillingInfo), sut.PropertyBag["billing"]);

    mocks.VerifyAll();
}

Just by changing from SetupResult.For to Expect.Call we are now explicitly checking that controller gets its billing information using the correct user ID.  We also added in a VerifyAll call.  Now if the purchaseService.GetBillingInfo method is called with anything other than 5, or not called, the test will fail.

By using dynamic mocks we've verified just enough to see if our SUT works without adding a bunch of noise or unneeded fragility to our tests.

I finally figured out why my code snippets are all so horribly formatted via RSS, and it has nothing to do with the different source code formatters I've been using and everything to do with dasBlog.  I grabbed the dasBlog source and found the problem is with dasBlog's HTML tidy class, but more importantly I also found in the source how to disable it.  The latest dasBlog source has an option to disable formatting.

In the latest version of dasBlog they've added a setting to disable RSS formatting. Notice the setting even mentions "may mess up pre whitespace."  Mess up pre whitespace?  Yeah, no kidding.

At least now I don't have to switch blogging platforms, as the upgrade to dasBlog 2.0 is a whole lot easier.  Here's the dasBlog source code that optionally disables the formatting:

if (siteConfig.HtmlTidyContent == false)
{
    item.Description = "<div>" + PreprocessItemContent(entry.EntryId, entry.Content) + "</div>";
}
else
{
    item.Description = ContentFormatter.FormatContentAsHTML(PreprocessItemContent(entry.EntryId, entry.Content));
}

After much trial and error I finally gave up and asked Ayende what he uses to post to his blog.  His posts are always nicely formatted - including code snippets in Google Reader

It's that code snippet part that I have problems with, so I'm going to give the Syntax Highlighter for WLW that Ayende uses a shot.  If it works for him, it should work for me. Lets give it another shot shall we?

[TestFixture]
public class UnitOfWorkTests
{
    [Test]
    public void Should_return_same_instance()
    {
        var c = new Customer { Address = new Address(), CustomerID = 1, Name = "Sneal" };

        UnitOfWork uow = new UnitOfWork(new StubDataStore());
        uow.Save(c);

        Assert.AreSame(c, uow.Single(new Customer { CustomerID = 1 }));
    }

    [Test]
    public void Can_save_instance()
    {
        var c = new Customer { Address = new Address(), CustomerID = 1, Name = "Sneal" };

        UnitOfWork uow = new UnitOfWork(new StubDataStore());
        uow.Save(c);       
    }
}

Well that was nice, and boy does this thing support a lot of programming languages (way more than I know).

I've been using Windows Live Writer for a while now and would never go back to directly posting via a webform, WLW is just too easy.

I brought the topic of code comments up the other day at lunch to get some other's opinions about method level and class level comments, more specifically C# XML comments.  I brought the subject up because we have a policy at work to comment all methods, public and private, which I'm a bit dubious about.

It was interesting to see how widely opinions varied on the subject, from everything should be commented to produce nice CHM files to my position that comments are a last resort to explain the code to the next developer.

The best code needs no commenting at all.

public string ConcatStrings(string lhs, string rhs)
{
    return lhs + rhs;
}

That's good code.  Why?  Because I finally figured out how to join to strings together!  That may be part of it, but I deem this method pretty decent for the additional following reasons:

1. Fluent name, the method name describes exactly what the method does.
2. Short method.  The method name describes everything the method does because its small.

I think one of the best and easiest techniques to producing self documenting code is to use the extract method refactoring.  Take some code, extract a well named method out of it, and the readability goes up.

Fluent interfaces and DSL's take readable code a step further, and I think that's why they've become so popular. That, and its so damn easy to write an internal DSL in the cool popular dynamic languages like Ruby.  Why write comments buried in source code when you can write beautiful code instead? 

Have you seen developers obsessed with comments to the point of idiocy?  I know I have where I began to suspect the developer actually enjoyed writing comments more than code, or maybe writing code was too difficult for them so they focused on the low hanging fruit of comments?  Have your secretary comment your code, we as programmers should focus on writing code, good code.

Comments are not for documenting who made changes or when.  Heard of source control comments?  Heard of blame?  No?  Go learn them now.  In my experience DBA's are the worst offenders of this horrible practice, there must be something in their paranoid nature that makes them do this... obsessively.  There's absolutely no reason to litter beautiful code with code change comments, doing so only muddles the clear waters of code.

Back to my original point, I wait until I'm ready to checkin to add my comments.  In fact adding comments is one of my checkin practices.  Adding comments before then is often a waste of time.  How often have you written a method, an entire class, or even an entire namespace that never sees the light of source control?  I've mercilessly axed more JavaDoc comments and classes than I care to remember... more than I probably ever checked in.

And then the other day Jeff Atwood had a blog post about comments, and he said very concisely what I was thinking at lunch.

When you've rewritten, refactored, and rearchitected your code a dozen times to make it easy for your fellow developers to read and understand -- when you can't possibly imagine any conceivable way your code could be changed to become more straightforward and obvious -- then, and only then, should you feel compelled to add a comment explaining what your code does.

If there ever were a take away about a discussion around code comments, that's it.  Well put Jeff.

If you wait until you're happy with a piece of code, when its truly done enough to checkin you'll write less comments and better code.  Remember code comments can be a code smell.

I'm trying out a new Live Writer code formatting add in. I've had mixed results with the others I've used.  It seems I can't find one that is:

1. Easy to setup and use.  Copy, paste, done.
2. Works on my blog page.
3. Also works in RSS readers like Google Reader.

Lets see how the Insert from Visual Studio addin works...

[TestFixture]
public class UnitOfWorkTests
{
    [Test]
    public void Should_return_same_instance()
    {
        var c = new Customer { Address = new Address(), CustomerID = 1, Name = "Sneal" };

        UnitOfWork uow = new UnitOfWork(new StubDataStore());
        uow.Save(c);

        Assert.AreSame(c, uow.Single(new Customer { CustomerID = 1 }));
    }

    [Test]
    public void Can_save_instance()
    {
        var c = new Customer { Address = new Address(), CustomerID = 1, Name = "Sneal" };

        UnitOfWork uow = new UnitOfWork(new StubDataStore());
        uow.Save(c);       
    }
}

If nothing else, at least it looks pretty from Live Writer.  Lets see when it gets out in the wild...

Specifically ID and CLASS attributes are case sensitive when it comes to CSS.  If you take a look at the HTML 4 spec you'll notice that both ID and CSS have [CS] annotation for case-sensitive. 

Although this has always been the case, very few developers know this as a fact.  Its obvious Microsoft missed this in the first few HTML 4 compatible versions of IE.  In fact it wasn't until IE 6, when run in strict mode, would IE in fact honor the case sensitive nature of the CLASS and ID attribute.

I think its because of the early IE 'quirks' mode implementation that very few developers actually know that ID and CLASS are in fact case sensitive. They may guess correctly, but very few actually know this from experience.  A simple quiz at work today confirmed my suspicion.

Well after today, I know from experience that CSS is case sensitive.  <div class="msg-Error"/>  is not the same as  <div class="msg-error"/>.

So in summary if your CSS is not getting applied as expected you might want to check the casing between your HTML and your CSS.

I committed an example class library (utility) which drives some JsUnit tests and gathers the results.  This is handy if you want the results inside of a C# application or an NUnit test.  Basically the JsUnit webform is posted to an ASHX handler running under the .NET 2.0 webserver. 

Its not real pretty or that usable in its current form, but it has some good starting points. I'm not sure it actually works since I lost the original source code and had to decompile it using Reflector.  It at least compiles...  Do whatever you like with the source, its available in my SVN repository here.

You may or may not know that for the past year I've been working for a small startup, GalleryPlayer.  For the most part I'm glad to have had the opportunity to work there, I was able to touch a lot of new technology and learn a lot all while delivering business value.  Overall I was able to learn and grow while there, so I'll chalk that up as a win for me.

Unfortunately as with a lot of startups GalleryPlayer hit a rough spot. We'll leave it at that...

As of July 14th I'm now working with a lot of really great people at Daptiv.  I'm excited to work with a team who are not only smart and driven, but understand the value of agile development and TDD.  There's no convincing that needs to happen, no cowboys that need reigning in, everything is already setup and ready to rock.

Its refreshing to be able to walk into a well organized team and not have technical debt frustrating you at every turn.  This has had a huge impact on keeping my overall stress level at an all time low for being a FNG.  Yes, there is still technical debt (there always is), but the fundamentals are already taken care of, and that makes me very happy.

Perhaps I'm exaggerating a little bit, but if you look at the claims Gallio makes you might be tempted to agree with me. 

The Gallio platform seeks to facilitate the creation of a rich ecosystem of interoperable testing tools...  they should present consistent interfaces to the world so that they can easily be integrated into the systems and processes of the enterprise.  At present Gallio can run tests from MbUnit versions 2 and 3, MSTest, NBehave, NUnit, and xUnit.Net.  Gallio provides tool support and integration with CCNet, MSBuild, NAnt, NCover, Pex, Powershell, Resharper, TestDriven.Net, TypeMock, and Visual Studio Team System.

That's a lot of integrations!

The UI runner that comes with Gallio is pretty and for the most part functional - remember this is an alpha!  I did have some issues when I tried loading several thousand tests into the UI.  Things got slow and a little wonky while it scanned for tests in my assembly. A couple of times it crashed on on me after reloading the assembly after a recompilation. Then again I'm not sure if NUnit is any better in this type of scenario.

Gallio sounds like a real benefit for organizations using MSTest that are looking to upgrade to a real xUnit framework.  At the very least you can ditch the lackluster MSTest runner in favor of a better runner like ReSharper, which is what I'm currently trying to do.  Unfortunately there's an issue with Gallio that makes all the tests report back a status of 'skipped.'  Luckily this is an OSS project with public source code...

Gallio makes working with different open source projects very easy from my point of view.  Now I can use a common interface (ReSharper 4.0 test runner) for all my testing needs regardless of the OSS project's test runner... no need to fire up MBUnit GUI or NUnit or whatever.  It all just works and doesn't interrupt my flow.  I imagine the number of testing frameworks and tools for Gallio will almost certainly grow over time. 

This is definitely one of the more useful testing tools I've seen recently.  Why?  Because it reduces friction.

I think Jeff Atwood hit the nail on the head when he said:

It's an open secret in the blogging community that the comments are often better than the original blog entry itself. Would you browse Amazon without the user reviews? No? Then why would you willingly choose to run your blog that way?

Don't be afraid of comments. Embrace them. Moderate them. The community will respect you for it, and your blog will be better for it as well.

Not only are comments sometimes interesting potentially offering differing points of view, but more than once I've had someone find my blog and leave a comment which solves the issue I was having.  How cool is that?  Even better, the next person having the same issue might be led to my blog by Google and find the answer right there in the comment.

Comments are valuable, which made me realize I need to do everything I can to help encourage comments.  The default setup for leaving comments in dasBlog is too much work IMO and overall isn't a great experience.  So last week I decided to improve the comment experience on this blog.  Here's a summary of what I did:

1. Turned off CoComments which implied an extra form to fill out to submit a comment.  I think this just annoyed people and kept them from commenting. I know I didn't like the extra step.
2. I added Gravatars, which are global recognized avatars (i.e.they work on any site that supports them).  I think this really helps people identify the comment author and makes the comment a touch more personal.
3. I enabled comments to always show on a post entry.  Previously an extra click was required to see comments... which discouraged people to read or add comments.  Now comments always show because comments are important.  I find it almost silly that dasBlog warns against enabling this setting - granted it says for high volume sites (which isn't me).
4. Email addresses are now hidden on the blog post entry.  I think most people don't really like their email addresses showing up even if they are somewhat obfuscated on the blog post page.  From now on your email address will not show, but will still allow me to reply back to you via email.  When I reply to a comment I will post it to this blog and then reply to your email with my comment so that you know I've responded.  Unfortunately I couldn't find a way for dasBlog to automatically do this for me.

I'm hoping these changes will make my blog a bit more comment friendly for everyone.  So, try it out and let me know what you think... by leaving a comment ;)