What we’re talking about is a C# specification monad, striving to do for the individual what LINQ does for the many. Pattern matching is about as functional as it gets; constructing an object tree (IConstraint) goes against the grain.

Imagine, instead of Assert.That() having 2 parameters, it were to return something like IConstrainable. This would allow us to write assertions of arbitrary complexity, something like:

Assert.That(text).IsEmailAddress().WithLength(1, 200);

or

Assert.That(customer).IsPreferred();

Now, as we move away from simply renaming well-known constructs, extension methods start to make things simpler. Contrast:

Assert.IsTrue(n % 2 == 0);

with

Assert.That(n).IsEven();

- or -

Assert.IsTrue(n >= 0 && n <= 100);

with

Assert.That(n).IsPercentage();

Within a framework like this, the “basic” operations are needed to maintain a consistent level of abstraction:

Assert.That(n).IsEven().IsInRange(0, 42).IsNotEqualTo(21);

Just some things to think about.

(Full disclosure: I am working on just such a project)

BTW first time reading the blog, am really enjoying the content.

I do concede your point that this has a place; I am really just arguing for some consistency across syntax so that when unfamiliar people view the code, its understandable.

I’m all in favor of ‘fluent’ interfaces but only so long as they are actually ALSO ‘comprehensible’ intefaces. IMO fluency is about ease of SPEAKING something and comprehension is about ease of READING something and we all know that code gets read many more times than it gets written. So long as ‘ease of coding’ doesn’t lead to ‘difficulty in reading’, I’m all for the introduction of these things.

But I really feel strongly that ‘extension-method-enabled API pollution’ needs to be recognized as a very real threat to the approachability and readability (and by this I really mean COMPREHENSION) of code — a balance needs to be struck here and that’s really all I’m aruging for (some reasonable restraint)

Thanks for the comment~!

1. Extending (adding assertions) doesn’t cause name overload issues. What should I name the static class? What class do I find the “AllInstancesShouldNotBeNull” assertion on? With extension methods I just have to add a using and call “Assert.That(foo).ShouldNotHaveNullItems()”. When adding assertions I don’t have to care about the class name, as generally the user won’t be exposed to it.

2. It helps intellisense. All assertions start with “Assert.That(foo)”. Then intellisense will let me know what assertions are available for the specific type I’m asserting on.

Traditional assertion APIs are clumsy to use in comparison to the fluent APIs. So much so, that I don’t think a unit test framework developed today would include any assertions that are not fluent in nature.

I think that its entirely likely that many of the “shoulds” and “ought-to’s” that I am seeing out there are indeed the result of (reasonably) well-meaning BDD-focused individuals as my own experience suggests that it tends to be the BDD-ers that are most obssessed with the language used to describe their tests (and assertions).

I actually think that BDD as a thought process has a lot to offer in re: the way it makes you focus on the behavior of your softare rather than its ‘outputs’. And as a guide to help developers focus on testing ‘what matters’ rather than over-spefifying brittle tests of things that don’t, I am inclined to give a nod to BDD as being helpful there.

But I also firmly believe that one can successfully practice BDD by stating test methods in terms of desired behaviors rather than convoluted assertions. Assertions like .ShouldEqual(), .ShouldBe(), and others aren’t really that useful to me when compared against the API pollution that I was alluding to here. A test method called ‘Should_Prevent_User_from_Logging_On()’ is useful to me as a BDD-friendly syntax so that I can see what’s passing/failing in a result report. But Assert.That(actual).ShouldBe(expected) is starting to trend towards API self-flaggelation in my book and adds little value to the assertion/failure process (IMHO).

My experience with lovers of such language contortions is the same as my experience with many of the DDD-minded set out there: many tend to accept BDD (or DDD) as some kind of ‘religion’ that must be fervently adhered to in all ways, no matter the cost. When people start quoting scripture to me (even if its Evans instead of Matthew or Luke) I tend to tune them out

What about the concept of BDD vs. TDD? I would like to hear you thoughts on BDD, do you believe that BDD is designed to get you to think correctly about what you are testing? Would you consider this methodology?
Just curious :).

Thanks.