{"id":2721,"date":"2015-01-07T13:00:32","date_gmt":"2015-01-07T13:00:32","guid":{"rendered":"http:\/\/writeasync.net\/?p=2721"},"modified":"2015-01-05T23:55:37","modified_gmt":"2015-01-05T23:55:37","slug":"fluent-async-testing","status":"publish","type":"post","link":"http:\/\/writeasync.net\/?p=2721","title":{"rendered":"Fluent async testing"},"content":{"rendered":"

Cellfish writes<\/a>:<\/p>\n

When .net 4.5 was first in public beta most test frameworks had a bug making it impossible to write async test methods. I wish they had never fixed that because I don’t think those help you write good tests.<\/p><\/blockquote>\n

I completely agree and as a rule I never write async Task<\/code>-returning test methods. The drawback is that doing this carefully means making sure the Task<\/code> is in the desired state, unpacking inner exceptions from an expected AggregateException<\/code><\/a>, and other tedium.<\/p>\n

Really, though, this is a general problem in unit testing, when assertions pile up and become more structural than logical. Consider this sample test for a fictional ItemCounter<\/code>:<\/p>\n

\r\npublic void GivenTwoPrefixMatchesFindByPrefixShouldReturnBothItems()\r\n{\r\n    ItemCounter counter = new ItemCounter();\r\n    counter.Increment("A1");\r\n    counter.Increment("A2");\r\n    counter.Increment("A2");\r\n\r\n    IDictionary<string, int> counts = counter.FindByPrefix("A");\r\n\r\n    Assert.AreEqual(2, counts.Count);\r\n    Assert.IsTrue(counts.ContainsKey("A1"));\r\n    Assert.AreEqual(1, counts["A1"]);\r\n    Assert.IsTrue(counts.ContainsKey("A2"));\r\n    Assert.AreEqual(2, counts["A2"]);\r\n}\r\n<\/pre>\n
While this isn’t the worst<\/em> possible example, it is indicative of a lot of day-to-day code I see. As the number of still logically-related but structurally different checks increases, these assertions become visual clutter and make tests more tedious and opaque than they need to be.<\/p>\n
As a first-level refactoring you can always hide the clutter and take a page from the xUnit Patterns<\/a> playbook, Custom Assertion<\/a>:<\/p>\n
\r\npublic void GivenTwoPrefixMatchesFindByPrefixShouldReturnBothItems()\r\n{\r\n    ItemCounter counter = new ItemCounter();\r\n    counter.Increment("A1");\r\n    counter.Increment("A2");\r\n    counter.Increment("A2");\r\n\r\n    IDictionary<string, int> counts = counter.FindByPrefix("A");\r\n\r\n    Assert.AreEqual(2, counts.Count);\r\n    AssertHasItem(counts, "A1", 1);\r\n    AssertHasItem(counts, "A2", 2);\r\n}\r\n\r\nprivate static void AssertHasItem<TKey, TValue>(IDictionary<TKey, TValue> items, TKey key, TValue value)\r\n{\r\n    Assert.IsTrue(items.ContainsKey(key));\r\n    Assert.AreEqual(value, items[key]);\r\n}\r\n<\/pre>\n
This helps readability quite a bit. However, the style is still not quite “fluent” (as in, “reads like a natural sentence”) and the error messages are no better than before. You can spot fix those problems, expand your custom assertions to be more generic, and so on. But it’s not going to be trivial (see e.g. Owen Pellegrin wrestle with this problem<\/a>).<\/p>\n
Thankfully, it turns out Dennis Doomen<\/a> and others have already solved many of these problems in a low-friction reusable library.<\/p>\n
Enter Fluent Assertions<\/a>.<\/h3>\n
Using Fluent Assertions<\/a>, we can rewrite our test like so:<\/p>\n
\r\n\/\/ ...\r\nusing FluentAssertions;\r\n\/\/ ...\r\npublic void GivenTwoPrefixMatchesFindByPrefixShouldReturnBothItems()\r\n{\r\n    ItemCounter counter = new ItemCounter();\r\n    counter.Increment("A1");\r\n    counter.Increment("A2");\r\n    counter.Increment("A2");\r\n\r\n    IDictionary<string, int> counts = counter.FindByPrefix("A");\r\n\r\n    counts.Should().HaveCount(2).And.Contain("A1", 1).And.Contain("A2", 2);\r\n}\r\n<\/pre>\n
The full assertion now fits comfortably on a single line, is easy to write, and it doesn’t get much more fluent than this. The error messages are also a breath of fresh air and give exact details of what went wrong:<\/p>\n