http://www.clariusconsulting.net/blogs/kzu/archive/2008/03/10/58301.aspx

Consider two hypotheticals:

Assert.IsTrue(someVal, “Should be true”);

Assert.That(someVal).Is(true).Otherwise(“Should be true”);

When I read code, I want to read CODE, not English words with horrible character delimiting.

I agree, I also find discoverability to be a missing part of the puzzle. I haven’t explored this space massively but I like fluent interfaces to be very discoverable, I want them to lead me in the right direction and I find most don’t, they produce readable results but only but working out how to get the fluent interface to do what I want isn’t any easier than with a normal interface in a lot of cases right now.

FLUENT implies that its easy to SAY something which (when intellisense is your only composition tool) is rarely the case with many of these. I don’t want to see verbs in my intellisense list, I want to see methods named something like the action I’m trying to achieve in my code. When I see .Is().Not()….. code, a little bit of the professional inside of me dies

It may very well be that once written these interfaces are indeed more LEGIBLE than otherwise, but calling them fluent as though they make it easier to SAY what you mean is a red-herring for all but the best of these approaches. Things like FluentNHibernate and the Windsor Registration syntax are arguably much better than their XML alternatives in many regards, but even if they had been coded in non-fluent-interface-style this same would be true of them IMHO.

Fluent NHibernate and Windsor Registration are two that really come to mind. No more xml hell and I can dot through the configuration with intellisense and the code becomes intention revealing. Very nice!

As for the two examples above they are abusive, but thats still a good thing. We need to test the limits before we know what works and what doesn’t.

I would take it a step further and using something like this:

Assert.True(contidition.IsEqualTo(5))

I use these types of extensions in some of out internal framework code because:

if(result.IsEqualTo(expected))

looks better than

if(result == expected)