ploeh blog https://blog.ploeh.dk danish software design en-us Mark Seemann Tue, 26 Mar 2019 13:45:13 UTC Tue, 26 Mar 2019 13:45:13 UTC An example of state based-testing in F# https://blog.ploeh.dk/2019/03/25/an-example-of-state-based-testing-in-f/ Mon, 25 Mar 2019 06:34:00 UTC <div id="post"> <p> <em>While F# is a functional-first language, it's okay to occasionally be pragmatic and use mutable state, for example to easily write some sustainable state-based tests.</em> </p> <p> This article is an instalment in an article series about how to move <a href="/2019/02/18/from-interaction-based-to-state-based-testing">from interaction-based testing to state-based testing</a>. In the previous article, you saw how to write <a href="/2019/03/11/an-example-of-state-based-testing-in-haskell">state-based tests in Haskell</a>. In this article, you'll see how to apply what you've learned in <a href="https://fsharp.org">F#</a>. </p> <p> The code shown in this article is <a href="https://github.com/ploeh/UserManagement">available on GitHub</a>. </p> <h3 id="57929a79c0a740c5986df12fc6e4b1c1"> A function to connect two users <a href="#57929a79c0a740c5986df12fc6e4b1c1" title="permalink">#</a> </h3> <p> This article, like the others in this series, implements an operation to connect two users. I explain the example in details in my two <a href="https://cleancoders.com">Clean Coders</a> videos, <a href="https://cleancoders.com/episode/humane-code-real-episode-4/show">Church Visitor</a> and <a href="https://cleancoders.com/episode/humane-code-real-episode-5/show">Preserved in translation</a>. </p> <p> Like in the previous <a href="https://www.haskell.org">Haskell</a> example, in this article we'll start with the implementation, and then see how to unit test it. </p> <p> <pre><span style="color:green;">//&nbsp;(&#39;a&nbsp;-&gt;&nbsp;Result&lt;User,UserLookupError&gt;)&nbsp;-&gt;&nbsp;(User&nbsp;-&gt;&nbsp;unit)&nbsp;-&gt;&nbsp;&#39;a&nbsp;-&gt;&nbsp;&#39;a&nbsp;-&gt;&nbsp;HttpResponse&lt;User&gt;</span> <span style="color:blue;">let</span>&nbsp;post&nbsp;lookupUser&nbsp;updateUser&nbsp;userId&nbsp;otherUserId&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;userRes&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;lookupUser&nbsp;userId&nbsp;|&gt;&nbsp;Result.mapError&nbsp;(<span style="color:blue;">function</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;InvalidId&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:#a31515;">&quot;Invalid&nbsp;user&nbsp;ID.&quot;</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;NotFound&nbsp;&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:#a31515;">&quot;User&nbsp;not&nbsp;found.&quot;</span>) &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;otherUserRes&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;lookupUser&nbsp;otherUserId&nbsp;|&gt;&nbsp;Result.mapError&nbsp;(<span style="color:blue;">function</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;InvalidId&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:#a31515;">&quot;Invalid&nbsp;ID&nbsp;for&nbsp;other&nbsp;user.&quot;</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;NotFound&nbsp;&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:#a31515;">&quot;Other&nbsp;user&nbsp;not&nbsp;found.&quot;</span>) &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;connect&nbsp;=&nbsp;result&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let!</span>&nbsp;user&nbsp;=&nbsp;userRes &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let!</span>&nbsp;otherUser&nbsp;=&nbsp;otherUserRes &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;addConnection&nbsp;user&nbsp;otherUser&nbsp;|&gt;&nbsp;updateUser &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;otherUser&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">match</span>&nbsp;connect&nbsp;<span style="color:blue;">with</span>&nbsp;Ok&nbsp;u&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;OK&nbsp;u&nbsp;|&nbsp;Error&nbsp;msg&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;BadRequest&nbsp;msg</pre> </p> <p> While <a href="/2019/02/25/an-example-of-interaction-based-testing-in-c">the original C# example</a> used Constructor Injection, the above <code>post</code> function uses <a href="/2017/01/30/partial-application-is-dependency-injection">partial application for Dependency Injection</a>. The two function arguments <code>lookupUser</code> and <code>updateUser</code> represent interactions with a database. Since functions are polymorphic, however, it's possible to replace them with <a href="http://xunitpatterns.com/Test%20Double.html">Test Doubles</a>. </p> <h3 id="dd0384ed4c2d478f8374dbd55c86b197"> A Fake database <a href="#dd0384ed4c2d478f8374dbd55c86b197" title="permalink">#</a> </h3> <p> Like in the Haskell example, you can implement a <a href="http://xunitpatterns.com/Fake%20Object.html">Fake</a> database in F#. It's also possible to implement the State monad in F#, but there's less need for it. F# is a functional-first language, but you can also write mutable code if need be. You could, then, choose to be pragmatic and base your Fake database on mutable state. </p> <p> <pre><span style="color:blue;">type</span>&nbsp;FakeDB&nbsp;()&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;users&nbsp;=&nbsp;Dictionary&lt;int,&nbsp;User&gt;&nbsp;() &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">member</span>&nbsp;<span style="color:blue;">val</span>&nbsp;IsDirty&nbsp;=&nbsp;<span style="color:blue;">false</span>&nbsp;<span style="color:blue;">with</span>&nbsp;get,&nbsp;set &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">member</span>&nbsp;this.AddUser&nbsp;user&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;this.IsDirty&nbsp;<span style="color:blue;">&lt;-</span>&nbsp;<span style="color:blue;">true</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;users.Add&nbsp;(user.UserId,&nbsp;user) &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">member</span>&nbsp;this.TryFind&nbsp;i&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">match</span>&nbsp;users.TryGetValue&nbsp;i&nbsp;<span style="color:blue;">with</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;<span style="color:blue;">false</span>,&nbsp;_&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;None &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;<span style="color:blue;">true</span>,&nbsp;&nbsp;u&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;Some&nbsp;u &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">member</span>&nbsp;this.LookupUser&nbsp;s&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">match</span>&nbsp;Int32.TryParse&nbsp;s&nbsp;<span style="color:blue;">with</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;<span style="color:blue;">false</span>,&nbsp;_&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;Error&nbsp;InvalidId &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;<span style="color:blue;">true</span>,&nbsp;i&nbsp;<span style="color:blue;">-&gt;</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">match</span>&nbsp;users.TryGetValue&nbsp;i&nbsp;<span style="color:blue;">with</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;<span style="color:blue;">false</span>,&nbsp;_&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;Error&nbsp;NotFound &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;<span style="color:blue;">true</span>,&nbsp;u&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;Ok&nbsp;u &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">member</span>&nbsp;this.UpdateUser&nbsp;u&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;this.IsDirty&nbsp;<span style="color:blue;">&lt;-</span>&nbsp;<span style="color:blue;">true</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;users.[u.UserId]&nbsp;<span style="color:blue;">&lt;-</span>&nbsp;u</pre> </p> <p> This <code>FakeDB</code> type is <em>a class</em> that wraps a mutable dictionary. While it 'implements' <code>LookupUser</code> and <code>UpdateUser</code>, it also exposes what <a href="http://bit.ly/xunitpatterns">xUnit Test Patterns</a> calls a <em>Retrieval Interface:</em> an API that tests can use to examine the state of the object. </p> <p> Immutable values normally have structural equality. This means that two values are considered equal if they contain the same constituent values, and have the same structure. Mutable objects, on the other hand, typically have reference equality. This makes it harder to compare two objects, which is, however, what almost all unit testing is about. You compare expected state with actual state. </p> <p> In the previous article, the Fake database was simply an immutable dictionary. This meant that tests could easily compare expected and actual values, since they were immutable. When you use a mutable object, like the above dictionary, this is harder. Instead, what I chose to do here was to introduce an <code>IsDirty</code> flag. This enables easy verification of whether or not the database changed. </p> <h3 id="88dbfa0dd8f34f4ba91f2b7acc6173b1"> Happy path test case <a href="#88dbfa0dd8f34f4ba91f2b7acc6173b1" title="permalink">#</a> </h3> <p> This is all you need in terms of Test Doubles. You now have test-specific <code>LookupUser</code> and <code>UpdateUser</code> methods that you can pass to the <code>post</code> function. </p> <p> Like in the previous article, you can start by exercising the happy path where a user successfully connects with another user: </p> <p> <pre>[&lt;Fact&gt;] <span style="color:blue;">let</span>&nbsp;``Users&nbsp;successfully&nbsp;connect``&nbsp;()&nbsp;=&nbsp;Property.check&nbsp;&lt;|&nbsp;property&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let!</span>&nbsp;user&nbsp;=&nbsp;Gen.user &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let!</span>&nbsp;otherUser&nbsp;=&nbsp;Gen.withOtherId&nbsp;user &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;db&nbsp;=&nbsp;FakeDB&nbsp;() &nbsp;&nbsp;&nbsp;&nbsp;db.AddUser&nbsp;user &nbsp;&nbsp;&nbsp;&nbsp;db.AddUser&nbsp;otherUser &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;actual&nbsp;=&nbsp;post&nbsp;db.LookupUser&nbsp;db.UpdateUser&nbsp;(string&nbsp;user.UserId)&nbsp;(string&nbsp;otherUser.UserId) &nbsp;&nbsp;&nbsp;&nbsp;test&nbsp;&lt;@&nbsp;db.TryFind&nbsp;user.UserId &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&gt;&nbsp;Option.exists &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(<span style="color:blue;">fun</span>&nbsp;u&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;u.ConnectedUsers&nbsp;|&gt;&nbsp;List.contains&nbsp;otherUser)&nbsp;@&gt; &nbsp;&nbsp;&nbsp;&nbsp;test&nbsp;&lt;@&nbsp;isOK&nbsp;actual&nbsp;@&gt;&nbsp;}</pre> </p> <p> All tests in this article use <a href="https://xunit.github.io">xUnit.net</a> 2.3.1, <a href="https://github.com/SwensenSoftware/unquote">Unquote</a> 4.0.0, and <a href="https://github.com/hedgehogqa/fsharp-hedgehog">Hedgehog</a> 0.7.0.0. </p> <p> This test first adds two valid users to the Fake database <code>db</code>. It then calls the <code>post</code> function, passing the <code>db.LookupUser</code> and <code>db.UpdateUser</code> methods as arguments. Finally, it verifies that the 'first' user's <code>ConnectedUsers</code> now contains the <code>otherUser</code>. It also verifies that <code>actual</code> represents a <code>200 OK</code> HTTP response. </p> <h3 id="750f435b6e854db898e0da44119ee4f6"> Missing user test case <a href="#750f435b6e854db898e0da44119ee4f6" title="permalink">#</a> </h3> <p> While there's one happy-path test case, there's four other test cases left. One of these is when the first user doesn't exist: </p> <p> <pre>[&lt;Fact&gt;] <span style="color:blue;">let</span>&nbsp;``Users&nbsp;don&#39;t&nbsp;connect&nbsp;when&nbsp;user&nbsp;doesn&#39;t&nbsp;exist``&nbsp;()&nbsp;=&nbsp;Property.check&nbsp;&lt;|&nbsp;property&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let!</span>&nbsp;i&nbsp;=&nbsp;Range.linear&nbsp;1&nbsp;1_000_000&nbsp;|&gt;&nbsp;Gen.int &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let!</span>&nbsp;otherUser&nbsp;=&nbsp;Gen.user &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;db&nbsp;=&nbsp;FakeDB&nbsp;() &nbsp;&nbsp;&nbsp;&nbsp;db.AddUser&nbsp;otherUser &nbsp;&nbsp;&nbsp;&nbsp;db.IsDirty&nbsp;<span style="color:blue;">&lt;-</span>&nbsp;<span style="color:blue;">false</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;uniqueUserId&nbsp;=&nbsp;string&nbsp;(otherUser.UserId&nbsp;+&nbsp;i) &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;actual&nbsp;=&nbsp;post&nbsp;db.LookupUser&nbsp;db.UpdateUser&nbsp;uniqueUserId&nbsp;(string&nbsp;otherUser.UserId) &nbsp;&nbsp;&nbsp;&nbsp;test&nbsp;&lt;@&nbsp;not&nbsp;db.IsDirty&nbsp;@&gt; &nbsp;&nbsp;&nbsp;&nbsp;test&nbsp;&lt;@&nbsp;isBadRequest&nbsp;actual&nbsp;@&gt;&nbsp;}</pre> </p> <p> This test adds one valid user to the Fake database. Once it's done with configuring the database, it sets <code>IsDirty</code> to <code>false</code>. The <code>AddUser</code> method sets <code>IsDirty</code> to <code>true</code>, so it's important to reset the flag before the <em>act</em> phase of the test. You could consider this a bit of a hack, but I think it makes the intent of the test clear. This is, however, a position I'm ready to reassess should the tests evolve to make this design awkward. </p> <p> As explained in the previous article, this test case requires an ID of a user that doesn't exist. Since this is a property-based test, there's a risk that Hedgehog might generate a number <code>i</code> equal to <code>otherUser.UserId</code>. One way to get around that problem is to add the two numbers together. Since <code>i</code> is generated from the range <em>1 - 1,000,000</em>, <code>uniqueUserId</code> is guaranteed to be different from <code>otherUser.UserId</code>. </p> <p> The test verifies that the state of the database didn't change (that <code>IsDirty</code> is still <code>false</code>), and that <code>actual</code> represents a <code>400 Bad Request</code> HTTP response. </p> <h3 id="4dbe21251f8440b1a594192d07b53c9f"> Remaining test cases <a href="#4dbe21251f8440b1a594192d07b53c9f" title="permalink">#</a> </h3> <p> You can write the remaining three test cases in the same vein: </p> <p> <pre>[&lt;Fact&gt;] <span style="color:blue;">let</span>&nbsp;``Users&nbsp;don&#39;t&nbsp;connect&nbsp;when&nbsp;other&nbsp;user&nbsp;doesn&#39;t&nbsp;exist``&nbsp;()&nbsp;=&nbsp;Property.check&nbsp;&lt;|&nbsp;property&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let!</span>&nbsp;i&nbsp;=&nbsp;Range.linear&nbsp;1&nbsp;1_000_000&nbsp;|&gt;&nbsp;Gen.int &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let!</span>&nbsp;user&nbsp;=&nbsp;Gen.user &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;db&nbsp;=&nbsp;FakeDB&nbsp;() &nbsp;&nbsp;&nbsp;&nbsp;db.AddUser&nbsp;user &nbsp;&nbsp;&nbsp;&nbsp;db.IsDirty&nbsp;<span style="color:blue;">&lt;-</span>&nbsp;<span style="color:blue;">false</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;uniqueOtherUserId&nbsp;=&nbsp;string&nbsp;(user.UserId&nbsp;+&nbsp;i) &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;actual&nbsp;=&nbsp;post&nbsp;db.LookupUser&nbsp;db.UpdateUser&nbsp;(string&nbsp;user.UserId)&nbsp;uniqueOtherUserId&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;test&nbsp;&lt;@&nbsp;not&nbsp;db.IsDirty&nbsp;@&gt; &nbsp;&nbsp;&nbsp;&nbsp;test&nbsp;&lt;@&nbsp;isBadRequest&nbsp;actual&nbsp;@&gt;&nbsp;} [&lt;Fact&gt;] <span style="color:blue;">let</span>&nbsp;``Users&nbsp;don&#39;t&nbsp;connect&nbsp;when&nbsp;user&nbsp;Id&nbsp;is&nbsp;invalid``&nbsp;()&nbsp;=&nbsp;Property.check&nbsp;&lt;|&nbsp;property&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let!</span>&nbsp;s&nbsp;=&nbsp;Gen.alphaNum&nbsp;|&gt;&nbsp;Gen.string&nbsp;(Range.linear&nbsp;0&nbsp;100)&nbsp;|&gt;&nbsp;Gen.filter&nbsp;isIdInvalid &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let!</span>&nbsp;otherUser&nbsp;=&nbsp;Gen.user &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;db&nbsp;=&nbsp;FakeDB&nbsp;() &nbsp;&nbsp;&nbsp;&nbsp;db.AddUser&nbsp;otherUser &nbsp;&nbsp;&nbsp;&nbsp;db.IsDirty&nbsp;<span style="color:blue;">&lt;-</span>&nbsp;<span style="color:blue;">false</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;actual&nbsp;=&nbsp;post&nbsp;db.LookupUser&nbsp;db.UpdateUser&nbsp;s&nbsp;(string&nbsp;otherUser.UserId) &nbsp;&nbsp;&nbsp;&nbsp;test&nbsp;&lt;@&nbsp;not&nbsp;db.IsDirty&nbsp;@&gt; &nbsp;&nbsp;&nbsp;&nbsp;test&nbsp;&lt;@&nbsp;isBadRequest&nbsp;actual&nbsp;@&gt;&nbsp;} [&lt;Fact&gt;] <span style="color:blue;">let</span>&nbsp;``Users&nbsp;don&#39;t&nbsp;connect&nbsp;when&nbsp;other&nbsp;user&nbsp;Id&nbsp;is&nbsp;invalid``&nbsp;()&nbsp;=&nbsp;Property.check&nbsp;&lt;|&nbsp;property&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let!</span>&nbsp;s&nbsp;=&nbsp;Gen.alphaNum&nbsp;|&gt;&nbsp;Gen.string&nbsp;(Range.linear&nbsp;0&nbsp;100)&nbsp;|&gt;&nbsp;Gen.filter&nbsp;isIdInvalid &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let!</span>&nbsp;user&nbsp;=&nbsp;Gen.user &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;db&nbsp;=&nbsp;FakeDB&nbsp;() &nbsp;&nbsp;&nbsp;&nbsp;db.AddUser&nbsp;user &nbsp;&nbsp;&nbsp;&nbsp;db.IsDirty&nbsp;<span style="color:blue;">&lt;-</span>&nbsp;<span style="color:blue;">false</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;actual&nbsp;=&nbsp;post&nbsp;db.LookupUser&nbsp;db.UpdateUser&nbsp;(string&nbsp;user.UserId)&nbsp;s &nbsp;&nbsp;&nbsp;&nbsp;test&nbsp;&lt;@&nbsp;not&nbsp;db.IsDirty&nbsp;@&gt; &nbsp;&nbsp;&nbsp;&nbsp;test&nbsp;&lt;@&nbsp;isBadRequest&nbsp;actual&nbsp;@&gt;&nbsp;}</pre> </p> <p> All tests inspect the state of the Fake database after the calling the <code>post</code> function. The exact interactions between <code>post</code> and <code>db</code> aren't specified. Instead, these tests rely on setting up the initial state, exercising the System Under Test, and verifying the final state. These are all state-based tests that avoid over-specifying the interactions. </p> <h3 id="102ff7e3a9b247b4914f113b06afd6df"> Summary <a href="#102ff7e3a9b247b4914f113b06afd6df" title="permalink">#</a> </h3> <p> While the previous Haskell example demonstrated that it's possible to write state-based unit tests in a functional style, when using F#, it sometimes make sense to leverage the object-oriented features already available in the .NET framework, such as mutable dictionaries. It would have been possible to write purely functional state-based tests in F# as well, by porting the Haskell examples, but here, I wanted to demonstrate that this isn't required. </p> <p> I tend to be of the opinion that it's only possible to be pragmatic if you know how to be dogmatic, but now that we know how to write state-based tests in a strictly functional style, I think it's fine to be pragmatic and use a bit of mutable state in F#. The benefit of this is that it now seems clear how to apply what we've learned to the original C# example. </p> <p> <strong>Next: </strong> An example of state based-testing in C#. </p> </div><hr> This blog is totally free, but if you like it, please consider <a href="https://blog.ploeh.dk/support">supporting it</a>. Mark Seemann https://blog.ploeh.dk/2019/03/25/an-example-of-state-based-testing-in-f The programmer as decision maker https://blog.ploeh.dk/2019/03/18/the-programmer-as-decision-maker/ Mon, 18 Mar 2019 07:44:00 UTC <div id="post"> <p> <em>As a programmer, your job is to make technical decisions. Make some more.</em> </p> <p> When <a href="/schedule">I speak at conferences</a>, people often come and talk to me. (I welcome that, BTW.) Among all the conversations I've had over the years, there's a pattern to some of them. The attendee will start by telling me how inspired (s)he is by the talk I just gave, or something I've written. That's gratifying, and a good way to start a conversation, but is often followed up like this: </p> <p> <strong>Attendee:</strong> "I just wish that we could do something like that in our organisation..." </p> <p> Let's just say that here we're talking about test-driven development, or perhaps just unit testing. Nothing too controversial. I'd typically respond, </p> <p> <strong>Me:</strong> "Why can't you?" </p> <p> <strong>Attendee:</strong> "Our boss won't let us..." </p> <p> That's unfortunate. If your boss has explicitly forbidden you to write and run unit tests, then there's not much you can do. Let me make this absolutely clear: I'm not going on record saying that you should actively disobey a direct order (unless it's unethical, that is). I do wonder, however: </p> <p> <em>Why is the boss even involved in that decision?</em> </p> <p> It seems to me that programmers often defer too much authority to their managers. </p> <h3 id="510367ded1ca47e7922b540d2fff50b0"> A note on culture <a href="#510367ded1ca47e7922b540d2fff50b0" title="permalink">#</a> </h3> <p> I'd like to preface the rest of this article with my own context. I've spent most of my programming career in Danish organisations. Even when I worked for Microsoft, I worked for Danish subsidiaries, with Danish managers. </p> <p> The power distance in Denmark is (in)famously short. It's not unheard of for individual contributors to question their superiors' decisions; sometimes to their face, and sometimes even when other people witness this. When done respectfully (which it often is), this can be extremely efficient. Managers are as fallible as the rest of us, and often their subordinates know of details that could impact a decision that a manager is about to make. Immediately discussing such details can help ensure that good decisions are made, and bad decisions are cancelled. </p> <p> This helps managers make better decisions, so enlightened managers welcome feedback. </p> <p> In general, Danish employees also tend to have a fair degree of autonomy. What I'll suggest in this article is unlikely to get you fired in Denmark. Please use your own judgement if you consider transplanting the following to your own culture. </p> <h3 id="eaa896ed8a6240729301c54fed859ab7"> Technical decisions <a href="#eaa896ed8a6240729301c54fed859ab7" title="permalink">#</a> </h3> <p> If your job is <em>programmer</em>, <em>software developer</em>, or similar, the value you add to the team is that you bring <em>technical expertise</em>. Maybe some of your colleagues are programmers as well, but together, you are the people with the technical expertise. </p> <p> Even if the project manager or other superiors used to program, unless they're also writing code for the current code base, they only have general technical expertise, but not specific expertise related to the code base you're working with. The people with most technical expertise are you and your colleagues. </p> <p> You are decision makers. </p> <p> Whenever you interact with your code base, you make technical decisions. </p> <p> In order to handle incoming HTTP requests to a <code>/reservations</code> resource, you may first decide to create a <a href="/2019/02/11/asynchronous-injection">new file called <code>ReservationsController.cs</code></a>. You'd most likely also decide to open that file and start adding code to it. </p> <p> Perhaps you add a method called <code>Post</code> that takes a <code>Reservation</code> argument. Perhaps you decide to inject an <code>IMaîtreD</code> dependency. </p> <p> At various steps along the way, you may decide to compile the code. </p> <p> Once you think that you've made enough changes to address your current work item, you may decide to run the program to see if it works. For a web-based piece of software, that typically involves starting up a browser and somehow interacting with the service. If your program is a web site, you may start at the front page, log in, click around, and fill in some forms. If your program is a REST API, you may interact with it via Fiddler or Postman (I prefer curl or <a href="https://github.com/ploeh/Furl">Furl</a>, but most people I've met still prefer something they can click on, it seems). </p> <p> What often happens is that your changes don't work the first time around, so you'll have to troubleshoot. Perhaps you decide to use a debugger. </p> <p> How many decisions are that? </p> <p> I just described seven or eight types of the sort of decisions you make as a programmer. You make such decisions all the time. Do you ask your managers permission before you start a debugging session? Before you create a new file? Before you name a variable? </p> <p> Of course you don't. You're the technical expert. There's no-one better equipped than you or your team members to make those decisions. </p> <h3 id="bed169525ccf4a90aaa9c0e33fcbf8d0"> Decide to add unit tests <a href="#bed169525ccf4a90aaa9c0e33fcbf8d0" title="permalink">#</a> </h3> <p> If you want to add unit tests, why don't you just decide to add them? If you want to apply test-driven development, why don't you just do so? </p> <p> A unit test is one or more code files. You're already authorised to make decisions about adding files. </p> <p> You can run a test suite instead of launching the software every time you want to interact with it. It's likely to be faster, even. </p> <p> Why should you ask permission to do that? </p> <h3 id="e42aac76e52141e68a0bc08fefa56a9b"> Decide to refactor <a href="#e42aac76e52141e68a0bc08fefa56a9b" title="permalink">#</a> </h3> <p> Another complaint I hear is that people aren't allowed to refactor. </p> <p> Why are you even asking permission to refactor? </p> <p> <a href="http://amzn.to/YPdQDf">Refactoring</a> means reorganising the code without changing the behaviour of the system. Another word for that is <em>editing</em> the code. It's okay. You're already permitted to edit code. It's part of your job description. </p> <p> I think I know what the underlying problem is, though... </p> <h3 id="f8c290ef29bd437daf2a81b3e06e131c"> Make technical decisions in the small <a href="#f8c290ef29bd437daf2a81b3e06e131c" title="permalink">#</a> </h3> <p> As an individual contributor, you're empowered to make small-scale technical decisions. These are decisions that are unlikely to impact schedules or allocation of programmers, including new hires. Big decisions probably should involve your manager. </p> <p> I have an inkling of why people feel that they need permission to refactor. It's because the refactoring they have in mind is going to take weeks. Weeks in which nothing else can be done. Weeks where perhaps the code doesn't even compile. </p> <p> Many years ago (but not as many as I'd like it to be), my colleague and I had what Eric Evans in <a href="http://amzn.to/WBCwx7">DDD</a> calls a <em>breakthrough</em>. We wanted to refactor towards deeper insight. What prompted the insight was a new feature that we had to add, and we'd been throwing design ideas back and forth for some time before the new insight arrived. </p> <p> We could implement the new feature if we changed one of the core abstractions in our domain model, but it required substantial changes to the existing code base. We informed our manager of our new insight and our plan, estimating that it would take less than a week to make the changes and implement the new feature. Our manager agreed with the plan. </p> <p> Two weeks later our code hadn't been in a compilable state for a week. Our manager pulled me away to tell me, quietly and equitably, that he was not happy with our lack of progress. I could only concur. </p> <p> After more heroic work, we finally managed to complete the changes and implement the new feature. Nonetheless, blocking all other development for two-three weeks in order to make a change isn't acceptable. </p> <p> That sort of change is a big decision because it impacts other team members, schedules, and perhaps overall business plans. Don't make those kinds of decisions without consulting with stakeholders. </p> <p> This still leaves, I believe, lots of room for individual decision-making in the small. What I learned from the experience I just recounted was not to engage in big changes to a code base. Learn how to make multiple incremental changes instead. In case that's completely impossible, add the new model side-by-side with the old model, and incrementally change over. That's what I should have done those many years ago. </p> <h3 id="298ca23885544e5f906379c1a6d15586"> Don't be sneaky <a href="#298ca23885544e5f906379c1a6d15586" title="permalink">#</a> </h3> <p> When I give talks about the blessings of functional programming, I sometimes get into another type of discussion. </p> <p> <strong>Attendee:</strong> It's so inspiring how beautiful and simple complex domain models become in <a href="https://fsharp.org">F#</a>. How can we do the same in C#? </p> <p> <strong>Me:</strong> You can't. If you're already using C#, you should strongly consider F# if you wish to do functional programming. Since it's also a .NET language, you can gradually introduce F# code and mix the compiled code with your existing C# code. </p> <p> <strong>Attendee:</strong> Yes... [already getting impatient with me] But we can't do that... </p> <p> <strong>Me:</strong> Why not? </p> <p> <strong>Attendee:</strong> Because our manager will not allow it. </p> <p> Based on the suggestions I've already made here, you may expect me to say that that's another technical decision that you should make without asking permission. Like the previous example about blocking refactorings, however, this is another large-scale decision. </p> <p> Your manager may be concerned that it'd be hard to find new employees if the code base is written in some niche language. <a href="/2015/12/03/the-rules-of-attraction-language">I tend to disagree with that position</a>, but I do understand why a manager would take that position. While I think it suboptimal to restrict an entire development organisation to a single language (whether it's C#, Java, C++, Ruby, etc.), I'll readily accept that language choice is a strategic decision. </p> <p> If every programmer got to choose the programming language they prefer the most that day, you'd have code bases written in dozens of different languages. While you can train bright new hires to learn a new language or two, it's unrealistic that a new employee will be able to learn thirty different languages in a short while. </p> <p> I find it reasonable that a manager has the final word on the choice of language, even when I often disagree with the decisions. </p> <p> The outcome usually is that people are stuck with C# (or Java, or...). Hence the question: <em>How can we do functional programming in C#?</em> </p> <p> I'll give the answer that I often give here on the blog: <a href="https://en.wikipedia.org/wiki/Mu_(negative)">mu</a> (<em>unask the question</em>). You can, in fact, translate functional concepts to C#, but <a href="/2018/07/24/dependency-injection-revisited">the result is so non-idiomatic</a> that only the syntax remains of C#: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IReservationsInstruction</span>&lt;<span style="color:#2b91af;">TResult</span>&gt;&nbsp;Select&lt;<span style="color:#2b91af;">T</span>,&nbsp;<span style="color:#2b91af;">TResult</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">IReservationsInstruction</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;source, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">T</span>,&nbsp;<span style="color:#2b91af;">TResult</span>&gt;&nbsp;selector) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;source.Match&lt;<span style="color:#2b91af;">IReservationsInstruction</span>&lt;<span style="color:#2b91af;">TResult</span>&gt;&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;isReservationInFuture:&nbsp;t&nbsp;=&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">IsReservationInFuture</span>&lt;<span style="color:#2b91af;">TResult</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Tuple</span>&lt;<span style="color:#2b91af;">Reservation</span>,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">bool</span>,&nbsp;<span style="color:#2b91af;">TResult</span>&gt;&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t.Item1, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;b&nbsp;=&gt;&nbsp;selector(t.Item2(b)))), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;readReservations:&nbsp;t&nbsp;=&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ReadReservations</span>&lt;<span style="color:#2b91af;">TResult</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Tuple</span>&lt;<span style="color:#2b91af;">DateTimeOffset</span>,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">Reservation</span>&gt;,&nbsp;<span style="color:#2b91af;">TResult</span>&gt;&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t.Item1, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;d&nbsp;=&gt;&nbsp;selector(t.Item2(d)))), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;create:&nbsp;t&nbsp;=&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Create</span>&lt;<span style="color:#2b91af;">TResult</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Tuple</span>&lt;<span style="color:#2b91af;">Reservation</span>,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">int</span>,&nbsp;<span style="color:#2b91af;">TResult</span>&gt;&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t.Item1, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;r&nbsp;=&gt;&nbsp;selector(t.Item2(r))))); }</pre> </p> <p> Keep in mind the manager's motivation for standardising on C#. It's often related to concerns about being able to hire new employees, or move employees from project to project. </p> <p> If you write 'functional' C#, you'll end up with code like the above, or the following real-life example: </p> <p> <pre><span style="color:blue;">return</span>&nbsp;<span style="color:blue;">await</span>&nbsp;sendRequest( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">ApiMethodNames</span>.InitRegistration, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">GSObject</span>()) &nbsp;&nbsp;&nbsp;&nbsp;.Map(r&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">ValidateResponse</span>.Validate(r) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.MapFailure(_&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">ErrorResponse</span>.RegisterErrorResponse())) &nbsp;&nbsp;&nbsp;&nbsp;.Bind(r&nbsp;=&gt;&nbsp;r.RetrieveField(<span style="color:#a31515;">&quot;regToken&quot;</span>)) &nbsp;&nbsp;&nbsp;&nbsp;.BindAsync(token&nbsp;=&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sendRequest( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">ApiMethodNames</span>.RegisterAccount, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CreateRegisterRequest( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mailAddress, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;password, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;token)) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Map(<span style="color:#2b91af;">ValidateResponse</span>.Validate) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Bind(response&nbsp;=&gt;&nbsp;getIdentity(response) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.ToResult(<span style="color:#2b91af;">ErrorResponse</span>.ExternalServiceResponseInvalid))) &nbsp;&nbsp;&nbsp;&nbsp;.Map(id&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">GigyaIdentity</span>.CreateNewSiteUser(id.UserId,&nbsp;mailAddress));</pre> </p> <p> (I'm indebted to <a href="https://twitter.com/runeibsen">Rune Ibsen</a> for this example.) </p> <p> A new hire can have ten years of C# experience and still have no chance in a code base like that. You'll first have to teach him or her functional programming. If you can do that, you might as well also teach a new language, like F#. </p> <p> It's my experience that learning the syntax of a new language is easy, and usually doesn't take much time. The hard part is learning a new way to think. </p> <p> Writing 'functional' C# makes it doubly hard on new team members. Not only do they have to learn a new paradigm (functional programming), but they have to learn it in a language unsuited for that paradigm. </p> <p> That's why I think you should unask the question. If your manager doesn't want to allow F#, then writing 'functional' C# is just being sneaky. That'd be obeying the letter of the law while breaking the spirit of it. That is, in my opinion, immoral. Don't be sneaky. </p> <h3 id="2f1b38953bbc4814994ee471caf4c5ac"> Summary <a href="#2f1b38953bbc4814994ee471caf4c5ac" title="permalink">#</a> </h3> <p> As a professional programmer, your job is to be a technical expert. In normal circumstances (at least the ones I know from my own career), you have agency. In order to get anything done, you make small decisions all the time, such as editing code. That's not only okay, but expected of you. </p> <p> Some decision, on the other hand, can have substantial ramifications. Choosing to write code in an unsanctioned language tends to fall on the side where a manager should be involved in the decision. </p> <p> In between is a grey area. </p> <p> <img src="/content/binary/small-vs-big-decisions-gradient.png" alt="A spectrum of decisions from small to the left to big to the right."> </p> <p> I don't even consider adding unit tests to be in the grey area, but some refactorings may be. <blockquote> <p>"It's easier to ask forgiveness than it is to get permission."</p> <footer><cite>Grace Hopper</cite></footer> </blockquote> </p> <p> To navigate grey areas you need a moral compass. </p> <p> I'll let you be the final judge of what you can get away with, but I consider it both appropriate and ethical to make the decision to add unit tests, and to continually improve code bases. You shouldn't have to ask permission to do that. </p> </div> <div id="comments"> <hr> <h2 id="comments-header"> Comments </h2> <div class="comment" id="dd2ab8d5dc6e4c5f9e49d7d7f35a8759"> <div class="comment-author"><a href="https://github.com/chicocode">Francisco Berrocal</a></div> <div class="comment-content"> <p>Before all, I'd just like to thank all the content you share, they all make me think in a good way!</p> <p> Now regarding to this post, while I tend to agree that a developer can take the decision to add (or not) unit tests by himself, there is no great value comming out of it, if that's not an approach of the whole development team, right? I believe we need the entire team on board to maximize the values of unit tests. There are changes we need to consider, from changes in the mindset of how you develop to actually running them on continuour integration pipelines. Doesn't all of that push simple decisions like "add unit test" from green area towards orange area? </p> </div> <div class="comment-date">2019-03-18 13:14 UTC</div> </div> <div class="comment" id="2bc69a5123d8499ca40631b9ce946919"> <div class="comment-author"><a href="/">Mark Seemann</a></div> <div class="comment-content"> <p> Francisco, thank you for writing. If you have a team of developers, then I agree that unit tests are going to be most valuable if the team decides to use them. </p> <p> This is still something that you ought to be competent to decide as a self-organising team of developers. Do you need to ask a manager's permission? </p> <p> I'm not trying to pretend that this is easy. I realise that it can be difficult. </p> <p> I've heard about teams where other developers are hostile to the idea of unit testing. In that situation, I can offer no easy fixes. What a lone developer can try to do in that situation is to add and run unit tests locally, on his or her own machine. This will incur some friction, because other team members will be oblivious to the tests, so they'll change code that will cause those unit tests to break. </p> <p> This might teach the lone developer to write tests so that they're as robust to trivial changes as possible. That's a valuable skill in any case. There's still going to be some overhead of maintaining the unit tests in a scenario like that, but if that overhead is smaller than the productivity gained, then in might still be worthwhile. </p> <p> What might then happen could be that other developers who are on the fence see that the lone unit tester is more effective than they are. Perhaps they'll get curious about unit tests after all, once they can see the contours of advantages. </p> <p> The next scenario, then, is a team with a few developers writing unit tests, and other who don't. At some number, you'll have achieved enough critical mass that, at least, you get to check in the unit tests together with the source code. Soon after, you may be able to institute a policy that while not everyone writes unit tests, it's not okay to break existing tests. </p> <p> The next thing you can do, then, is to set up a test run as part of continuous integration and declare that a failing test run means that the build broke. You still have team members who don't write tests, but at least you get to do it, and the tests add value to the whole team. </p> <p> Perhaps the sceptics will slowly start to write unit tests over time. Some die-hards probably never will. </p> <p> You may be able to progress through such stages without asking a manager, but I do understand that there's much variation in organisation and team dynamics. If you can use any of the above sketches as inspiration, then that's great. If you (or other readers) have other success stories to tell, then please share them. </p> <p> The point I was trying to make with this article is that programmers have agency. This isn't a licence to do whatever you please. You still have to navigate the dynamics of whatever organisation you're in. You may not, however, need to ask your manager about every little thing that you're competent to decide yourselves. </p> </div> <div class="comment-date">2019-03-19 7:57 UTC</div> </div> <div class="comment"> <div class="comment-author"><a href="https://hettomei.github.io/">Timothée GAUTHIER</a></div> <div class="comment-content"> <p> Thank you A LOT for putting words on all these thought. You'll be my reference whenever I want to introduce unit test. </p> <p> My usual example is "a surgeon doesn't need to ask to the manager if he can wash his hand. Whashing his hand is part of his job". (Not mine, but I can't remember where it comes from) </p> </div> <div class="comment-date">2019-03-19 20:15 UTC</div> </div> </div> <hr> This blog is totally free, but if you like it, please consider <a href="https://blog.ploeh.dk/support">supporting it</a>. Mark Seemann https://blog.ploeh.dk/2019/03/18/the-programmer-as-decision-maker An example of state-based testing in Haskell https://blog.ploeh.dk/2019/03/11/an-example-of-state-based-testing-in-haskell/ Mon, 11 Mar 2019 07:55:00 UTC <div id="post"> <p> <em>How do you do state-based testing when state is immutable? You use the State monad.</em> </p> <p> This article is an instalment in an article series about how to move <a href="/2019/02/18/from-interaction-based-to-state-based-testing">from interaction-based testing to state-based testing</a>. In the previous article, you saw <a href="/2019/02/25/an-example-of-interaction-based-testing-in-c">an example of an interaction-based unit test</a> written in C#. The problem that this article series attempts to address is that interaction-based testing can lead to what <a href="http://bit.ly/xunitpatterns">xUnit Test Patterns</a> calls <em>Fragile Tests</em>, because the tests get coupled to implementation details, instead of overall behaviour. </p> <p> My experience is that functional programming is better aligned with unit testing because <a href="/2015/05/07/functional-design-is-intrinsically-testable">functional design is intrinsically testable</a>. While I believe that functional programming is no panacea, it still seems to me that we can learn many valuable lessons about programming from it. </p> <p> People often ask me about <a href="https://fsharp.org">F#</a> programming: <em>How do I know that my F# code is functional?</em> </p> <p> I sometimes wonder that myself, about my own F# code. One can certainly choose to ignore such a question as irrelevant, and I sometimes do, as well. Still, in my experience, asking such questions can create learning opportunities. </p> <p> The best answer that I've found is: <em>Port the F# code to <a href="https://www.haskell.org">Haskell</a>.</em> </p> <p> Haskell enforces <a href="https://en.wikipedia.org/wiki/Referential_transparency">referential transparency</a> via its compiler. If Haskell code compiles, it's functional. In this article, then, I take the problem from the previous article and port it to Haskell. </p> <p> The code shown in this article is <a href="https://github.com/ploeh/UserManagement">available on GitHub</a>. </p> <h3 id="ae68546c3d9f4810a18ea99c2bcc873c"> A function to connect two users <a href="#ae68546c3d9f4810a18ea99c2bcc873c" title="permalink">#</a> </h3> <p> In the previous article, you saw implementation and test coverage of a piece of software functionality to connect two users with each other. This was a simplification of the example running through my two <a href="https://cleancoders.com">Clean Coders</a> videos, <a href="https://cleancoders.com/episode/humane-code-real-episode-4/show">Church Visitor</a> and <a href="https://cleancoders.com/episode/humane-code-real-episode-5/show">Preserved in translation</a>. </p> <p> In contrast to the previous article, we'll start with the implementation of the System Under Test (SUT). </p> <p> <pre><span style="color:#2b91af;">post</span>&nbsp;::&nbsp;<span style="color:blue;">Monad</span>&nbsp;m&nbsp;<span style="color:blue;">=&gt;</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(a&nbsp;-&gt;&nbsp;m&nbsp;(Either&nbsp;UserLookupError&nbsp;User))&nbsp;-&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(User&nbsp;-&gt;&nbsp;m&nbsp;<span style="color:blue;">()</span>)&nbsp;-&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a&nbsp;-&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a&nbsp;-&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;m&nbsp;(HttpResponse&nbsp;User) post&nbsp;lookupUser&nbsp;updateUser&nbsp;userId&nbsp;otherUserId&nbsp;=&nbsp;<span style="color:blue;">do</span> &nbsp;&nbsp;userRes&nbsp;&lt;-&nbsp;first&nbsp;(\<span style="color:blue;">case</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;InvalidId&nbsp;-&gt;&nbsp;<span style="color:#a31515;">&quot;Invalid&nbsp;user&nbsp;ID.&quot;</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;NotFound&nbsp;&nbsp;-&gt;&nbsp;<span style="color:#a31515;">&quot;User&nbsp;not&nbsp;found.&quot;</span>) &nbsp;&nbsp;&nbsp;&nbsp;&lt;$&gt;&nbsp;lookupUser&nbsp;userId &nbsp;&nbsp;otherUserRes&nbsp;&lt;-&nbsp;first&nbsp;(\<span style="color:blue;">case</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;InvalidId&nbsp;-&gt;&nbsp;<span style="color:#a31515;">&quot;Invalid&nbsp;ID&nbsp;for&nbsp;other&nbsp;user.&quot;</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;NotFound&nbsp;&nbsp;-&gt;&nbsp;<span style="color:#a31515;">&quot;Other&nbsp;user&nbsp;not&nbsp;found.&quot;</span>) &nbsp;&nbsp;&nbsp;&nbsp;&lt;$&gt;&nbsp;lookupUser&nbsp;otherUserId &nbsp;&nbsp;connect&nbsp;&lt;-&nbsp;runExceptT&nbsp;$&nbsp;<span style="color:blue;">do</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;user&nbsp;&lt;-&nbsp;ExceptT&nbsp;$&nbsp;<span style="color:blue;">return</span>&nbsp;userRes &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;otherUser&nbsp;&lt;-&nbsp;ExceptT&nbsp;$&nbsp;<span style="color:blue;">return</span>&nbsp;otherUserRes &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;lift&nbsp;$&nbsp;updateUser&nbsp;$&nbsp;addConnection&nbsp;user&nbsp;otherUser &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;otherUser &nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;$&nbsp;either&nbsp;BadRequest&nbsp;OK&nbsp;connect </pre> </p> <p> This is as direct a translation of the C# code as makes sense. If I'd only been implementing the desired functionality in Haskell, without having to port existing code, I'd designed the code differently. </p> <p> This <code>post</code> function uses <a href="/2017/01/30/partial-application-is-dependency-injection">partial application as an analogy to dependency injection</a>, but in order to enable potentially impure operations to take place, everything must happen inside of some monad. While the production code must ultimately run in the <code>IO</code> monad in order to interact with a database, tests can choose to run in another monad. </p> <p> In the C# example, two dependencies are injected into the class that defines the <code>Post</code> method. In the above Haskell function, these two dependencies are instead passed as function arguments. Notice that both functions return values in the monad <code>m</code>. </p> <p> The intent of the <code>lookupUser</code> argument is that it'll query a database with a user ID. It'll return the user if present, but it could also return a <code>UserLookupError</code>, which is a simple <a href="https://en.wikipedia.org/wiki/Tagged_union">sum type:</a> </p> <p> <pre><span style="color:blue;">data</span>&nbsp;UserLookupError&nbsp;=&nbsp;InvalidId&nbsp;|&nbsp;NotFound&nbsp;<span style="color:blue;">deriving</span>&nbsp;(<span style="color:#2b91af;">Show</span>,&nbsp;<span style="color:#2b91af;">Eq</span>)</pre> </p> <p> If both users are found, the function connects the users and calls the <code>updateUser</code> function argument. The intent of this 'dependency' is that it updates the database. This is recognisably a <a href="https://en.wikipedia.org/wiki/Command%E2%80%93query_separation">Command</a>, since its return type is <code>m ()</code> - <a href="/2018/01/15/unit-isomorphisms"><em>unit</em> (<code>()</code>) is equivalent to <code>void</code></a>. </p> <h3 id="6855a96abefe47c3a924b6d7d94e7bc8"> State-based testing <a href="#6855a96abefe47c3a924b6d7d94e7bc8" title="permalink">#</a> </h3> <p> How do you unit test such a function? How do you use Mocks and Stubs in Haskell? You don't; you don't have to. While the <code>post</code> method <em>can</em> be impure (when <code>m</code> is <code>IO</code>), it doesn't have to be. Functional design is intrinsically testable, but that proposition depends on purity. Thus, it's worth figuring out how to keep the <code>post</code> function <a href="https://en.wikipedia.org/wiki/Pure_function">pure</a> in the context of unit testing. </p> <p> While <code>IO</code> implies impurity, most common monads are pure. Which one should you choose? You could attempt to entirely 'erase' the monadic quality of the <code>post</code> function with the <code>Identity</code> monad, but if you do that, you can't verify whether or not <code>updateUser</code> was invoked. </p> <p> While you <em>could</em> write an ad-hoc Mock using, for example, the <code>Writer</code> monad, it might be a better choice to investigate if something closer to state-based testing would be possible. </p> <p> In an object-oriented context, state-based testing implies that you exercise the SUT, which mutates some state, and then you verify that the (mutated) state matches your expectations. You can't do that when you test a pure function, but you can examine the state of the function's return value. The <code>State</code> monad is an obvious choice, then. </p> <h3 id="6d9ce24e5e374c5d9987ac481b1fbd37"> A Fake database <a href="#6d9ce24e5e374c5d9987ac481b1fbd37" title="permalink">#</a> </h3> <p> Haskell's <code>State</code> monad is parametrised on the state type as well as the normal 'value type', so in order to be able to test the <code>post</code> function, you'll have to figure out what type of state to use. The interactions implied by the <code>post</code> function's <code>lookupUser</code> and <code>updateUser</code> arguments are those of database interactions. A <a href="http://xunitpatterns.com/Fake%20Object.html">Fake</a> database seems an obvious choice. </p> <p> For the purposes of testing the <code>post</code> function, an in-memory database implemented using a <code>Map</code> is appropriate: </p> <p> <pre><span style="color:blue;">type</span>&nbsp;DB&nbsp;=&nbsp;Map&nbsp;Integer&nbsp;User</pre> </p> <p> This is simply a dictionary keyed by <code>Integer</code> values and containing <code>User</code> values. You can implement compatible <code>lookupUser</code> and <code>updateUser</code> functions with <code>State DB</code> as the <code>Monad</code>. The <code>updateUser</code> function is the easiest one to implement: </p> <p> <pre><span style="color:#2b91af;">updateUser</span>&nbsp;::&nbsp;<span style="color:blue;">User</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:blue;">State</span>&nbsp;<span style="color:blue;">DB</span>&nbsp;() updateUser&nbsp;user&nbsp;=&nbsp;modify&nbsp;$&nbsp;Map.insert&nbsp;(userId&nbsp;user)&nbsp;user</pre> </p> <p> This simply inserts the <code>user</code> into the database, using the <code>userId</code> as the key. The type of the function is compatible with the general requirement of <code>User -&gt; m ()</code>, since here, <code>m</code> is <code>State DB</code>. </p> <p> The <code>lookupUser</code> Fake implementation is a bit more involved: </p> <p> <pre><span style="color:#2b91af;">lookupUser</span>&nbsp;::&nbsp;<span style="color:#2b91af;">String</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:blue;">State</span>&nbsp;<span style="color:blue;">DB</span>&nbsp;(<span style="color:#2b91af;">Either</span>&nbsp;<span style="color:blue;">UserLookupError</span>&nbsp;<span style="color:blue;">User</span>) lookupUser&nbsp;s&nbsp;=&nbsp;<span style="color:blue;">do</span> &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;maybeInt&nbsp;=&nbsp;readMaybe&nbsp;s&nbsp;::&nbsp;Maybe&nbsp;Integer &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;eitherInt&nbsp;=&nbsp;<span style="color:blue;">maybe</span>&nbsp;(Left&nbsp;InvalidId)&nbsp;Right&nbsp;maybeInt &nbsp;&nbsp;db&nbsp;&lt;-&nbsp;get &nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;$&nbsp;eitherInt&nbsp;&gt;&gt;=&nbsp;<span style="color:blue;">maybe</span>&nbsp;(Left&nbsp;NotFound)&nbsp;Right&nbsp;.&nbsp;<span style="color:blue;">flip</span>&nbsp;Map.<span style="color:blue;">lookup</span>&nbsp;db</pre> </p> <p> First, consider the type. The function takes a <code>String</code> value as an argument and returns a <code>State DB (Either UserLookupError User)</code>. The requirement is a function compatible with the type <code>a -&gt; m (Either UserLookupError User)</code>. This works when <code>a</code> is <code>String</code> and <code>m</code> is, again, <code>State DB</code>. </p> <p> The entire function is written in <code>do</code> notation, where the inferred <code>Monad</code> is, indeed, <code>State DB</code>. The first line attempts to parse the <code>String</code> into an <code>Integer</code>. Since the built-in <code>readMaybe</code> function returns a <code>Maybe Integer</code>, the next line uses the <code>maybe</code> function to handle the two possible cases, converting the <code>Nothing</code> case into the <code>Left InvalidId</code> value, and the <code>Just</code> case into a <code>Right</code> value. </p> <p> It then uses the <code>State</code> module's <code>get</code> function to access the database <code>db</code>, and finally attempt a <code>lookup</code> against that <code>Map</code>. Again, <code>maybe</code> is used to convert the <code>Maybe</code> value returned by <code>Map.lookup</code> into an <code>Either</code> value. </p> <h3 id="280bfa2e191e42d095f6f762e0a94a55"> Happy path test case <a href="#280bfa2e191e42d095f6f762e0a94a55" title="permalink">#</a> </h3> <p> This is all you need in terms of <a href="http://xunitpatterns.com/Test%20Double.html">Test Doubles</a>. You now have test-specific <code>lookupUser</code> and <code>updateUser</code> functions that you can pass to the <code>post</code> function. </p> <p> Like in the previous article, you can start by exercising the happy path where a user successfully connects with another user: </p> <p> <pre>testProperty&nbsp;<span style="color:#a31515;">&quot;Users&nbsp;successfully&nbsp;connect&quot;</span>&nbsp;$&nbsp;\ &nbsp;&nbsp;user&nbsp;otherUser&nbsp;-&gt;&nbsp;runStateTest&nbsp;$&nbsp;<span style="color:blue;">do</span> &nbsp;&nbsp;put&nbsp;$&nbsp;Map.fromList&nbsp;[toDBEntry&nbsp;user,&nbsp;toDBEntry&nbsp;otherUser] &nbsp;&nbsp;actual&nbsp;&lt;-&nbsp;post&nbsp;lookupUser&nbsp;updateUser&nbsp;(<span style="color:blue;">show</span>&nbsp;$&nbsp;userId&nbsp;user)&nbsp;(<span style="color:blue;">show</span>&nbsp;$&nbsp;userId&nbsp;otherUser) &nbsp;&nbsp;db&nbsp;&lt;-&nbsp;get &nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;$ &nbsp;&nbsp;&nbsp;&nbsp;isOK&nbsp;actual&nbsp;&amp;&amp; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">any</span>&nbsp;(<span style="color:blue;">elem</span>&nbsp;otherUser&nbsp;.&nbsp;connectedUsers)&nbsp;(Map.<span style="color:blue;">lookup</span>&nbsp;(userId&nbsp;user)&nbsp;db)</pre> </p> <p> Here I'm <a href="/2018/05/07/inlined-hunit-test-lists">inlining test cases as anonymous functions</a> - this time expressing the tests as QuickCheck properties. I'll later return to the <code>runStateTest</code> helper function, but first I want to focus on the test body itself. It's written in <code>do</code> notation, and specifically, it runs in the <code>State DB</code> monad. </p> <p> <code>user</code> and <code>otherUser</code> are input arguments to the property. These are both <code>User</code> values, since the test also defines <code>Arbitrary</code> instances for that type (not shown in this article; see the source code repository for details). </p> <p> The first step in the test is to 'save' both users in the Fake database. This is easily done by converting each <code>User</code> value to a database entry: </p> <p> <pre><span style="color:#2b91af;">toDBEntry</span>&nbsp;::&nbsp;<span style="color:blue;">User</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;(<span style="color:#2b91af;">Integer</span>,&nbsp;<span style="color:blue;">User</span>) toDBEntry&nbsp;=&nbsp;userId&nbsp;&amp;&amp;&amp;&nbsp;<span style="color:blue;">id</span></pre> </p> <p> Recall that the Fake database is nothing but an alias over <code>Map Integer User</code>, so the only operation required to turn a <code>User</code> into a database entry is to extract the key. </p> <p> The next step in the test is to exercise the SUT, passing the test-specific <code>lookupUser</code> and <code>updateUser</code> Test Doubles to the <code>post</code> function, together with the user IDs converted to <code>String</code> values. </p> <p> In the <em>assert</em> phase of the test, it first extracts the current state of the database, using the <code>State</code> library's built-in <code>get</code> function. It then verifies that <code>actual</code> represents a <code>200 OK</code> value, and that the <code>user</code> entry in the database now contains <code>otherUser</code> as a connected user. </p> <h3 id="050ecaa9962a487c9381da982ab264e7"> Missing user test case <a href="#050ecaa9962a487c9381da982ab264e7" title="permalink">#</a> </h3> <p> While there's one happy-path test case, there's four other test cases left. One of these is when the first user doesn't exist: </p> <p> <pre>testProperty&nbsp;<span style="color:#a31515;">&quot;Users&nbsp;don&#39;t&nbsp;connect&nbsp;when&nbsp;user&nbsp;doesn&#39;t&nbsp;exist&quot;</span>&nbsp;$&nbsp;\ &nbsp;&nbsp;(Positive&nbsp;i)&nbsp;otherUser&nbsp;-&gt;&nbsp;runStateTest&nbsp;$&nbsp;<span style="color:blue;">do</span> &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;db&nbsp;=&nbsp;Map.fromList&nbsp;[toDBEntry&nbsp;otherUser] &nbsp;&nbsp;put&nbsp;db &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;uniqueUserId&nbsp;=&nbsp;<span style="color:blue;">show</span>&nbsp;$&nbsp;userId&nbsp;otherUser&nbsp;+&nbsp;i &nbsp;&nbsp;actual&nbsp;&lt;-&nbsp;post&nbsp;lookupUser&nbsp;updateUser&nbsp;uniqueUserId&nbsp;(<span style="color:blue;">show</span>&nbsp;$&nbsp;userId&nbsp;otherUser) &nbsp;&nbsp;assertPostFailure&nbsp;db&nbsp;actual</pre> </p> <p> What ought to trigger this test case is that the 'first' user doesn't exist, even if the <code>otherUser</code> does exist. For this reason, the test inserts the <code>otherUser</code> into the Fake database. </p> <p> Since the test is a QuickCheck property, <code>i</code> could be <em>any</em> positive <code>Integer</code> value - <em>including</em> the <code>userId</code> of <code>otherUser</code>. In order to properly exercise the test case, however, you'll need to call the <code>post</code> function with a <code>uniqueUserId</code> - thas it: an ID which is guaranteed to not be equal to the <code>userId</code> of <code>otherUser</code>. There's several options for achieving this guarantee (including, as you'll see soon, the <code>==&gt;</code> operator), but a simple way is to add a non-zero number to the number you need to avoid. </p> <p> You then exercise the <code>post</code> function and, as a verification, call a reusable <code>assertPostFailure</code> function: </p> <p> <pre><span style="color:#2b91af;">assertPostFailure</span>&nbsp;::&nbsp;(<span style="color:blue;">Eq</span>&nbsp;s,&nbsp;<span style="color:blue;">Monad</span>&nbsp;m)&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;s&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:blue;">HttpResponse</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:blue;">StateT</span>&nbsp;s&nbsp;m&nbsp;<span style="color:#2b91af;">Bool</span> assertPostFailure&nbsp;stateBefore&nbsp;resp&nbsp;=&nbsp;<span style="color:blue;">do</span> &nbsp;&nbsp;stateAfter&nbsp;&lt;-&nbsp;get &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;stateDidNotChange&nbsp;=&nbsp;stateBefore&nbsp;==&nbsp;stateAfter &nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;$&nbsp;stateDidNotChange&nbsp;&amp;&amp;&nbsp;isBadRequest&nbsp;resp</pre> </p> <p> This function verifies that the state of the database didn't change, and that the response value represents a <code>400 Bad Request</code> HTTP response. This verification doesn't actually verify that the error message associated with the <code>BadRequest</code> case is the expected message, like in the previous article. This would, however, involve a fairly trivial change to the code. </p> <h3 id="dbd934d3e4f7431d95d78dfb0c1d7f4e"> Missing other user test case <a href="#dbd934d3e4f7431d95d78dfb0c1d7f4e" title="permalink">#</a> </h3> <p> Similar to the above test case, users will also fail to connect if the 'other user' doesn't exist. The property is almost identical: </p> <p> <pre>testProperty&nbsp;<span style="color:#a31515;">&quot;Users&nbsp;don&#39;t&nbsp;connect&nbsp;when&nbsp;other&nbsp;user&nbsp;doesn&#39;t&nbsp;exist&quot;</span>&nbsp;$&nbsp;\ &nbsp;&nbsp;(Positive&nbsp;i)&nbsp;user&nbsp;-&gt;&nbsp;runStateTest&nbsp;$&nbsp;<span style="color:blue;">do</span> &nbsp;&nbsp; &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;db&nbsp;=&nbsp;Map.fromList&nbsp;[toDBEntry&nbsp;user] &nbsp;&nbsp;put&nbsp;db &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;uniqueOtherUserId&nbsp;=&nbsp;<span style="color:blue;">show</span>&nbsp;$&nbsp;userId&nbsp;user&nbsp;+&nbsp;i &nbsp;&nbsp;actual&nbsp;&lt;-&nbsp;post&nbsp;lookupUser&nbsp;updateUser&nbsp;(<span style="color:blue;">show</span>&nbsp;$&nbsp;userId&nbsp;user)&nbsp;uniqueOtherUserId &nbsp;&nbsp;assertPostFailure&nbsp;db&nbsp;actual</pre> </p> <p> Since this test body is so similar to the previous test, I'm not going to give you a detailed walkthrough. I did, however, promise to describe the <code>runStateTest</code> helper function: </p> <p> <pre><span style="color:#2b91af;">runStateTest</span>&nbsp;::&nbsp;<span style="color:blue;">State</span>&nbsp;(<span style="color:blue;">Map</span>&nbsp;k&nbsp;a)&nbsp;b&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;b runStateTest&nbsp;=&nbsp;<span style="color:blue;">flip</span>&nbsp;evalState&nbsp;Map.empty</pre> </p> <p> Since this is a one-liner, you could also write all the tests by simply in-lining that little expression, but I thought that it made the tests more readable to give this function an explicit name. </p> <p> It takes any <code>State (Map k a) b</code> and runs it with an empty map. Thus, all <code>State</code>-valued functions, like the tests, must explicitly put data into the state. This is also what the tests do. </p> <p> Notice that all the tests return <code>State</code> values. For example, the <code>assertPostFailure</code> function returns <code>StateT s m Bool</code>, of which <code>State s Bool</code> is an alias. This fits <code>State (Map k a) b</code> when <code>s</code> is <code>Map k a</code>, which again is aliased to <code>DB</code>. Reducing all of this, the tests are simply functions that return <code>Bool</code>. </p> <h3 id="bc67a5ebaf7347ffa4906b209c31d156"> Invalid user ID test cases <a href="#bc67a5ebaf7347ffa4906b209c31d156" title="permalink">#</a> </h3> <p> Finally, you can also cover the two test cases where one of the user IDs is invalid: </p> <p> <pre>testProperty&nbsp;<span style="color:#a31515;">&quot;Users&nbsp;don&#39;t&nbsp;connect&nbsp;when&nbsp;user&nbsp;Id&nbsp;is&nbsp;invalid&quot;</span>&nbsp;$&nbsp;\ &nbsp;&nbsp;s&nbsp;otherUser&nbsp;-&gt;&nbsp;isIdInvalid&nbsp;s&nbsp;==&gt;&nbsp;runStateTest&nbsp;$&nbsp;<span style="color:blue;">do</span> &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;db&nbsp;=&nbsp;Map.fromList&nbsp;[toDBEntry&nbsp;otherUser] &nbsp;&nbsp;put&nbsp;db &nbsp;&nbsp;actual&nbsp;&lt;-&nbsp;post&nbsp;lookupUser&nbsp;updateUser&nbsp;s&nbsp;(<span style="color:blue;">show</span>&nbsp;$&nbsp;userId&nbsp;otherUser) &nbsp;&nbsp;assertPostFailure&nbsp;db&nbsp;actual , testProperty&nbsp;<span style="color:#a31515;">&quot;Users&nbsp;don&#39;t&nbsp;connect&nbsp;when&nbsp;other&nbsp;user&nbsp;Id&nbsp;is&nbsp;invalid&quot;</span>&nbsp;$&nbsp;\ &nbsp;&nbsp;s&nbsp;user&nbsp;-&gt;&nbsp;isIdInvalid&nbsp;s&nbsp;==&gt;&nbsp;runStateTest&nbsp;$&nbsp;<span style="color:blue;">do</span> &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;db&nbsp;=&nbsp;Map.fromList&nbsp;[toDBEntry&nbsp;user] &nbsp;&nbsp;put&nbsp;db &nbsp;&nbsp;actual&nbsp;&lt;-&nbsp;post&nbsp;lookupUser&nbsp;updateUser&nbsp;(<span style="color:blue;">show</span>&nbsp;$&nbsp;userId&nbsp;user)&nbsp;s &nbsp;&nbsp;assertPostFailure&nbsp;db&nbsp;actual</pre> </p> <p> Both of these properties take a <code>String</code> value <code>s</code> as input. When QuickCheck generates a <code>String</code>, that could be any <code>String</code> value. Both tests require that the value is an invalid user ID. Specifically, it mustn't be possible to parse the string into an <code>Integer</code>. If you don't constrain QuickCheck, it'll generate various strings, including e.g. <code>"8"</code> and other strings that can be parsed as numbers. </p> <p> In the above <code>"Users don't connect when user doesn't exist"</code> test, you saw how one way to explicitly model constraints on data is to project a seed value in such a way that the constraint always holds. Another way is to use QuickCheck's built-in <code>==&gt;</code> operator to filter out undesired values. In this example, both tests employ the <code>isIdInvalid</code> function: </p> <p> <pre><span style="color:#2b91af;">isIdInvalid</span>&nbsp;::&nbsp;<span style="color:#2b91af;">String</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:#2b91af;">Bool</span> isIdInvalid&nbsp;s&nbsp;= &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;userInt&nbsp;=&nbsp;readMaybe&nbsp;s&nbsp;::&nbsp;Maybe&nbsp;Integer &nbsp;&nbsp;<span style="color:blue;">in</span>&nbsp;isNothing&nbsp;userInt</pre> </p> <p> Using <code>isIdInvalid</code> with the <code>==&gt;</code> operator guarantees that <code>s</code> is an invalid ID. </p> <h3 id="5d89ffd490454c0890dedff39c2f0852"> Summary <a href="#5d89ffd490454c0890dedff39c2f0852" title="permalink">#</a> </h3> <p> While state-based testing may, at first, sound incompatible with strictly functional programming, it's not only possible with the State monad, but even, with good language support, easily done. </p> <p> The tests shown in this article aren't concerned with the interactions between the SUT and its dependencies. Instead, they compare the initial state with the state after exercising the SUT. Comparing values, even complex data structures such as maps, tends to be trivial in functional programming. Immutable values typically have built-in structural equality (in Haskell signified by the automatic <code>Eq</code> type class), which makes comparing them trivial. </p> <p> Now that we know that state-based testing is possible even with Haskell's enforced purity, it should be clear that we can repeat the feat in F#. </p> <p> <strong>Next:</strong> <a href="/2019/03/25/an-example-of-state-based-testing-in-f">An example of state based-testing in F#</a>. </p> </div><hr> This blog is totally free, but if you like it, please consider <a href="https://blog.ploeh.dk/support">supporting it</a>. Mark Seemann https://blog.ploeh.dk/2019/03/11/an-example-of-state-based-testing-in-haskell Code quality isn't software quality https://blog.ploeh.dk/2019/03/04/code-quality-is-not-software-quality/ Mon, 04 Mar 2019 07:38:00 UTC <div id="post"> <p> <em>A trivial observation made explicit.</em> </p> <p> You'd think that it's evident that code quality and software quality are two different things. Yet, I often see or hear arguments about one or the other that indicates to me that some people don't make that distinction. I wonder why; I do. </p> <h3 id="56d219ddf746496c94b28d22def9a182"> Software quality <a href="#56d219ddf746496c94b28d22def9a182" title="permalink">#</a> </h3> <p> There's a school of thought leaders who advocate that, ultimately, we write code to solve problems, or to improve life, for people. I have nothing against that line of reasoning; it's just not one that I pursue much. Why should I use my energy on this message when someone like <a href="https://dannorth.net">Dan North</a> does it so much better than I could? </p> <p> Dan North is far from the only person making the point that our employers, or clients, or end-users don't care about the code; he is, in my opinion, one of the best communicators in that field. It makes sense that, with that perspective on software development, you'd invent something like <a href="https://en.wikipedia.org/wiki/Behavior-driven_development">behaviour-driven development</a>. </p> <p> The evaluation criterion used in this discourse is one of utility. Does the software serve a purpose? Does it do it well? </p> <p> In that light, <em>quality software</em> is software that serves its purpose beyond expectation. It rarely, if ever, crashes. It's easy to use. It's sufficiently responsive. It's pretty. It works both on-line and off-line. Attributes like that are externally observable qualities. </p> <p> You can write quality software in many different languages, using various styles. When you evaluate the externally observable qualities of software, the code is invisible. It's not part of the evaluation. </p> <p> It seems to me that some people try to make an erroneous conclusion from this premise. They'd say that since no employer, client, or end user evaluates the software based on the code that produced it, then no one cares about the code. </p> <h3 id="6bfca38c59a543b485fb2658ec86a615"> Code quality <a href="#6bfca38c59a543b485fb2658ec86a615" title="permalink">#</a> </h3> <p> It's easy to refute that argument. All you have to do is to come up with a counter-example. You just have to find <em>one</em> person who cares about the code. That's easy. </p> <p> <em>You</em> care about the code. </p> <p> Perhaps you react negatively to that assertion. Perhaps you say: <em>"No! I'm not one of those effete aesthetes who <a href="http://www.sandraandwoo.com/2015/12/24/0747-melodys-guide-to-programming-languages">only program in Plankalkül</a>."</em> Fine. Maybe you're not the type who likes to polish the code; maybe you're the practical, down-to-earth type who just likes to get stuff done, so that your employer/client/end-user is happy. </p> <p> Even so, I think that you still care about the code. Have you ever looked with bewilderment at a piece of code and thought: <em>"Who the hell wrote this piece of shit!?"</em> How many <a href="https://www.osnews.com/story/19266/wtfsm/">WTFs/m</a> is your code? </p> <p> I think every programmer cares about their code bases; if not in an active manner, then at least in a passive way. Bad code can seriously impede progress. I've seen more than one organisation effectively go out of business because of bad legacy code. </p> <p> Code quality is when you care about the readability and malleability of the code. It's when you care about the code's ability to <em>sustain</em> the business, not only today, but also in the future. </p> <h3 id="19f49a7c758947d9b9a8b4c52e2f8e8d"> Sustainable code <a href="#19f49a7c758947d9b9a8b4c52e2f8e8d" title="permalink">#</a> </h3> <p> I often get the impression that some people look at code quality and software quality as a (false) dichotomy. </p> <p> <img src="/content/binary/software-vs-code-quality-false-dichotomy.png" alt="Software quality versus code quality as a false dichotomy."> </p> <p> Such arguments often seem to imply that you can't have one without sacrificing the other. You must choose. </p> <p> The reality is, of course, that you can do both. </p> <p> <img src="/content/binary/software-code-quality-venn.png" alt="Software and code quality Venn diagram."> </p> <p> At the intersection between software and code quality the code sustains the business both now, and in the future. </p> <p> Yes, you should write code such that it produces software that provides value here and now, but you should also do your best to enable it to provide value in the future. This is <em>sustainable code</em>. It's code that can sustain the organisation during its lifetime. </p> <h3 id="1b88784a7a8a4ce5b44334a5ef474a85"> No gold-plating <a href="#1b88784a7a8a4ce5b44334a5ef474a85" title="permalink">#</a> </h3> <p> To be clear: this is not a call for <a href="https://en.wikipedia.org/wiki/Gold_plating_(project_management)">gold plating</a> or <a href="http://wiki.c2.com/?SpeculativeGenerality">speculative generality</a>. You probably can't predict the future needs of the stake-holders. </p> <p> Quality code doesn't have to be able to perfectly address all future requirements. In order to be sustainable, though, it should be easy to modify in the future, or perhaps just easy to throw away and rewrite. I think a good start is to write <a href="https://cleancoders.com/episode/humane-code-real-episode-1/show">humane code</a>; code that fits in your brain. </p> <p> At least, do your best to avoid writing legacy code. </p> <h3 id="74a27b6da02840919eed541b1c93f92f"> Summary <a href="#74a27b6da02840919eed541b1c93f92f" title="permalink">#</a> </h3> <p> Software quality and code quality can co-exist. You can write quality code that compiles to quality software, but one doesn't imply the other. These are two independent quality dimensions. </p> </div><hr> This blog is totally free, but if you like it, please consider <a href="https://blog.ploeh.dk/support">supporting it</a>. Mark Seemann https://blog.ploeh.dk/2019/03/04/code-quality-is-not-software-quality An example of interaction-based testing in C# https://blog.ploeh.dk/2019/02/25/an-example-of-interaction-based-testing-in-c/ Mon, 25 Feb 2019 05:42:00 UTC <div id="post"> <p> <em>An example of using Mocks and Stubs for unit testing in C#.</em> </p> <p> This article is an instalment in an article series about how to move <a href="/2019/02/18/from-interaction-based-to-state-based-testing">from interaction-based testing to state-based testing</a>. In this series, you'll be presented with some alternatives to interaction-based testing with Mocks and Stubs. Before we reach the alternatives, however, we need to establish an example of interaction-based testing, so that you have something against which you can compare those alternatives. In this article, I'll present a simple example, in the form of C# code. </p> <p> The code shown in this article is <a href="https://github.com/ploeh/UserManagement">available on GitHub</a>. </p> <h3 id="7cc38b5dd1bc44c6aacb5077ae65c288"> Connect two users <a href="#7cc38b5dd1bc44c6aacb5077ae65c288" title="permalink">#</a> </h3> <p> For the example, I'll use a simplified version of the example that runs through my two <a href="https://cleancoders.com">Clean Coders</a> videos, <a href="https://cleancoders.com/episode/humane-code-real-episode-4/show">Church Visitor</a> and <a href="https://cleancoders.com/episode/humane-code-real-episode-5/show">Preserved in translation</a>. </p> <p> The desired functionality is simple: implement a REST API that enables one user to connect to another user. You could imagine some sort of social media platform, or essentially any sort of online service where users might be interested in connecting with, or following, other users. </p> <p> In essence, you could imagine that a user interface makes an HTTP POST request against our REST API: </p> <p> <pre>POST /connections/42 HTTP/1.1 Content-Type: application/json { "otherUserId": 1337 }</pre> </p> <p> Let's further imagine that we implement the desired functionality with a C# method with this signature: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IHttpActionResult</span>&nbsp;Post(<span style="color:blue;">string</span>&nbsp;userId,&nbsp;<span style="color:blue;">string</span>&nbsp;otherUserId)</pre> </p> <p> We'll return to the implementation later, but I want to point out a few things. </p> <p> First, notice that both <code>userId</code> and <code>otherUserId</code> are <code>string</code> arguments. While the above example encodes both IDs as numbers, essentially, both URLs and JSON are text-based. Following <a href="https://en.wikipedia.org/wiki/Robustness_principle">Postel's law</a>, the method should also accept JSON like <code>{ "otherUserId": "1337" }</code>. That's the reason the <code>Post</code> method takes <code>string</code> arguments instead of <code>int</code> arguments. </p> <p> Second, the return type is <code>IHttpActionResult</code>. Don't worry if you don't know that interface. It's just a way to model HTTP responses, such as <code>200 OK</code> or <code>400 Bad Request</code>. </p> <p> Depending on the input values, and the state of the application, several outcomes are possible: <table> <col> <col> <colgroup span="3"></colgroup> <thead> <tr> <td colspan="2" rowspan="2"></td> <th colspan="3" scope="colgroup">Other user</th> </tr> <tr> <th scope="col">Found</th> <th scope="col">Not found</th> <th scope="col">Invalid</th> </tr> </thead> <tbody> <tr> <th rowspan="3" scope="rowgroup">User</th> <th scope="row">Found</th> <td><em>Other user</em></td> <td><code>"Other user not found."</code></td> <td><code>"Invalid ID for other user."</code></td> </tr> <tr> <th scope="row">Not found</th> <td><code>"User not found."</code></td> <td><code>"User not found."</code></td> <td><code>"User not found."</code></td> </tr> <tr> <th scope="row">Invalid</th> <td><code>"Invalid user ID."</code></td> <td><code>"Invalid user ID."</code></td> <td><code>"Invalid user ID."</code></td> </tr> </tbody> </table> You'll notice that although this is a 3x3 matrix, there's only five distinct outcomes. This is just an implementation decision. If the first user ID is invalid (e.g. if it's a string like <code>"foo"</code> that doesn't represent a number), then it doesn't matter if the other user exists. Likewise, even if the first user ID is well-formed, it might still be the case that no user with that ID exists in the database. </p> <p> The assumption here is that the underlying user database uses integers as row IDs. </p> <p> When both users are found, the other user should be returned in the HTTP response, like this: </p> <p> <pre>HTTP/1.1 200 OK Content-Type: application/json { "id": 1337, "name": "ploeh", "connections": [{ "id": 42, "name": "fnaah" }, { "id": 2112, "name": "ndøh" }] }</pre> </p> <p> The intent is that when the first user (e.g. the one with the <code>42</code> ID) successfully connects to user <em>1337</em>, a user interface can show the full details of the other user, including the other user's connections. </p> <h3 id="2f013c5e86ef4abda25de01c06a90f25"> Happy path test case <a href="#2f013c5e86ef4abda25de01c06a90f25" title="permalink">#</a> </h3> <p> Since there's five distinct outcomes, you ought to write at least five test cases. You could start with the happy-path case, where both user IDs are well-formed and the users exist. </p> <p> All tests in this article use <a href="https://xunit.github.io">xUnit.net</a> 2.3.1, <a href="https://github.com/moq/moq4">Moq</a> 4.8.1, and <a href="https://github.com/AutoFixture/AutoFixture">AutoFixture</a> 4.1.0. </p> <p> <pre>[<span style="color:#2b91af;">Theory</span>,&nbsp;<span style="color:#2b91af;">UserManagementTestConventions</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;UsersSuccessfullyConnect( &nbsp;&nbsp;&nbsp;&nbsp;[<span style="color:#2b91af;">Frozen</span>]<span style="color:#2b91af;">Mock</span>&lt;<span style="color:#2b91af;">IUserReader</span>&gt;&nbsp;readerTD, &nbsp;&nbsp;&nbsp;&nbsp;[<span style="color:#2b91af;">Frozen</span>]<span style="color:#2b91af;">Mock</span>&lt;<span style="color:#2b91af;">IUserRepository</span>&gt;&nbsp;repoTD, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">User</span>&nbsp;user, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">User</span>&nbsp;otherUser, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">ConnectionsController</span>&nbsp;sut) { &nbsp;&nbsp;&nbsp;&nbsp;readerTD &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Setup(r&nbsp;=&gt;&nbsp;r.Lookup(user.Id.ToString())) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Returns(<span style="color:#2b91af;">Result</span>.Success&lt;<span style="color:#2b91af;">User</span>,&nbsp;<span style="color:#2b91af;">IUserLookupError</span>&gt;(user)); &nbsp;&nbsp;&nbsp;&nbsp;readerTD &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Setup(r&nbsp;=&gt;&nbsp;r.Lookup(otherUser.Id.ToString())) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Returns(<span style="color:#2b91af;">Result</span>.Success&lt;<span style="color:#2b91af;">User</span>,&nbsp;<span style="color:#2b91af;">IUserLookupError</span>&gt;(otherUser)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;actual&nbsp;=&nbsp;sut.Post(user.Id.ToString(),&nbsp;otherUser.Id.ToString()); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;ok&nbsp;=&nbsp;<span style="color:#2b91af;">Assert</span>.IsAssignableFrom&lt;<span style="color:#2b91af;">OkNegotiatedContentResult</span>&lt;<span style="color:#2b91af;">User</span>&gt;&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;actual); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(otherUser,&nbsp;ok.Content); &nbsp;&nbsp;&nbsp;&nbsp;repoTD.Verify(r&nbsp;=&gt;&nbsp;r.Update(user)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Contains(otherUser.Id,&nbsp;user.Connections); }</pre> </p> <p> To be clear, as far as Overspecified Software goes, this isn't a bad test. It only has two Test Doubles, <code>readerTD</code> and <code>repoTD</code>. My current habit is to name any Test Double with the <em>TD</em> suffix (for <em>Test Double</em>), instead of explicitly naming them <code>readerStub</code> and <code>repoMock</code>. The latter would have been more correct, though, since the <code>Mock&lt;IUserReader&gt;</code> object is consistently used as a Stub, whereas the <code>Mock&lt;IUserRepository&gt;</code> object is used only as a Mock. This is as it should be, because it follows the rule that you should use <a href="/2013/10/23/mocks-for-commands-stubs-for-queries">Mocks for Commands, Stubs for Queries</a>. </p> <p> <code>IUserRepository.Update</code> is, indeed a Command: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IUserRepository</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;Update(<span style="color:#2b91af;">User</span>&nbsp;user); }</pre> </p> <p> Since the method returns <code>void</code>, unless it doesn't do anything at all, the only thing it can do is to somehow change the state of the system. The test verifies that <code>IUserRepository.Update</code> was invoked with the appropriate input argument. </p> <p> This is fine. </p> <p> I'd like to emphasise that this isn't the biggest problem with this test. A Mock like this verifies that a desired interaction took place. If <code>IUserRepository.Update</code> isn't called in this test case, it would constitute a defect. The software wouldn't have the desired behaviour, so the test ought to fail. </p> <p> The signature of <code>IUserReader.Lookup</code>, on the other hand, implies that it's a Query: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IUserReader</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IResult</span>&lt;<span style="color:#2b91af;">User</span>,&nbsp;<span style="color:#2b91af;">IUserLookupError</span>&gt;&nbsp;Lookup(<span style="color:blue;">string</span>&nbsp;id); }</pre> </p> <p> In C# and most other languages, you can't be sure that implementations of the <code>Lookup</code> method have no side effects. If, however, we assume that the code base in question obeys the <a href="http://en.wikipedia.org/wiki/Command%E2%80%93query_separation">Command Query Separation</a> principle, then, by elimination, this must be a Query (since it's not a Command, because the return type isn't <code>void</code>). </p> <p> For a detailed walkthrough of the <code>IResult&lt;S, E&gt;</code> interface, see my <a href="https://cleancoders.com/episode/humane-code-real-episode-5/show">Preserved in translation</a> video. It's just an <a href="/2018/06/11/church-encoded-either">Either</a> with different terminology, though. <code>Right</code> is equivalent to <code>SuccessResult</code>, and <code>Left</code> corresponds to <code>ErrorResult</code>. </p> <p> The test configures the <code>IUserReader</code> Stub twice. It's necessary to give the Stub some behaviour, but unfortunately you can't just use Moq's <code>It.IsAny&lt;string&gt;()</code> for configuration, because in order to model the test case, the reader should return two different objects for two different inputs. </p> <p> This starts to look like Overspecified Software. </p> <p> Ideally, a Stub should just be present to 'make happy noises' in case the SUT decides to interact with the dependency, but with these two <code>Setup</code> calls, the interaction is overspecified. The test is tightly coupled to how the SUT is implemented. If you change the interaction implemented in the <code>Post</code> method, you could break the test. </p> <p> In any case, what the test does specify is that when you query the <code>UserReader</code>, it returns a <code>Success</code> object for both user lookups, a <code>200 OK</code> result is returned, and the <code>Update</code> method was called with <code>user</code>. </p> <h3 id="e60081720b2e4468883e3b35b9555c47"> Invalid user ID test case <a href="#e60081720b2e4468883e3b35b9555c47" title="permalink">#</a> </h3> <p> If the first user ID is invalid (i.e. not an integer) then the return value should represent <code>400 Bad Request</code> and the message body should indicate as much. This test verifies that this is the case: </p> <p> <pre>[<span style="color:#2b91af;">Theory</span>,&nbsp;<span style="color:#2b91af;">UserManagementTestConventions</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;UsersFailToConnectWhenUserIdIsInvalid( &nbsp;&nbsp;&nbsp;&nbsp;[<span style="color:#2b91af;">Frozen</span>]<span style="color:#2b91af;">Mock</span>&lt;<span style="color:#2b91af;">IUserReader</span>&gt;&nbsp;readerTD, &nbsp;&nbsp;&nbsp;&nbsp;[<span style="color:#2b91af;">Frozen</span>]<span style="color:#2b91af;">Mock</span>&lt;<span style="color:#2b91af;">IUserRepository</span>&gt;&nbsp;repoTD, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">string</span>&nbsp;userId, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">User</span>&nbsp;otherUser, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">ConnectionsController</span>&nbsp;sut) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.False(<span style="color:blue;">int</span>.TryParse(userId,&nbsp;<span style="color:blue;">out</span>&nbsp;<span style="color:blue;">var</span>&nbsp;_)); &nbsp;&nbsp;&nbsp;&nbsp;readerTD &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Setup(r&nbsp;=&gt;&nbsp;r.Lookup(userId)) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Returns(<span style="color:#2b91af;">Result</span>.Error&lt;<span style="color:#2b91af;">User</span>,&nbsp;<span style="color:#2b91af;">IUserLookupError</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">UserLookupError</span>.InvalidId)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;actual&nbsp;=&nbsp;sut.Post(userId,&nbsp;otherUser.Id.ToString()); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;err&nbsp;=&nbsp;<span style="color:#2b91af;">Assert</span>.IsAssignableFrom&lt;<span style="color:#2b91af;">BadRequestErrorMessageResult</span>&gt;(actual); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(<span style="color:#a31515;">&quot;Invalid&nbsp;user&nbsp;ID.&quot;</span>,&nbsp;err.Message); &nbsp;&nbsp;&nbsp;&nbsp;repoTD.Verify(r&nbsp;=&gt;&nbsp;r.Update(<span style="color:#2b91af;">It</span>.IsAny&lt;<span style="color:#2b91af;">User</span>&gt;()),&nbsp;<span style="color:#2b91af;">Times</span>.Never()); }</pre> </p> <p> This test starts with a Guard Assertion that <code>userId</code> isn't an integer. This is mostly an artefact of using AutoFixture. Had you used specific example values, then this wouldn't have been necessary. On the other hand, had you written the test case as a property-based test, it would have been even more important to <a href="/2016/01/18/make-pre-conditions-explicit-in-property-based-tests">explicitly encode such a constraint</a>. </p> <p> Perhaps a better design would have been to use a domain-specific method to check for the validity of the ID, but there's always room for improvement. </p> <p> This test is more brittle than it looks. It only defines what should happen when <code>IUserReader.Lookup</code> is called with the invalid <code>userId</code>. What happens if <code>IUserReader.Lookup</code> is called with the <code>Id</code> associated with <code>otherUser</code>? </p> <p> This currently doesn't matter, so the test passes. </p> <p> The test relies, however, on an implementation detail. This test implicitly assumes that the implementation short-circuits as soon as it discovers that <code>userId</code> is invalid. What if, however, you'd made some performance measurements, and you'd discovered that in most cases, the software would run faster if you <code>Lookup</code> both users in parallel? </p> <p> Such an innocuous performance optimisation could break the test, because the behaviour of <code>readerTD</code> is unspecified for all other cases than for <code>userId</code>. </p> <h3 id="d691fe8c85fa42b7baa3ad565c3e6f10"> Invalid ID for other user test case <a href="#d691fe8c85fa42b7baa3ad565c3e6f10" title="permalink">#</a> </h3> <p> What happens if the other user ID is invalid? This unit test exercises that test case: </p> <p> <pre>[<span style="color:#2b91af;">Theory</span>,&nbsp;<span style="color:#2b91af;">UserManagementTestConventions</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;UsersFailToConnectWhenOtherUserIdIsInvalid( &nbsp;&nbsp;&nbsp;&nbsp;[<span style="color:#2b91af;">Frozen</span>]<span style="color:#2b91af;">Mock</span>&lt;<span style="color:#2b91af;">IUserReader</span>&gt;&nbsp;readerTD, &nbsp;&nbsp;&nbsp;&nbsp;[<span style="color:#2b91af;">Frozen</span>]<span style="color:#2b91af;">Mock</span>&lt;<span style="color:#2b91af;">IUserRepository</span>&gt;&nbsp;repoTD, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">User</span>&nbsp;user, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">string</span>&nbsp;otherUserId, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">ConnectionsController</span>&nbsp;sut) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.False(<span style="color:blue;">int</span>.TryParse(otherUserId,&nbsp;<span style="color:blue;">out</span>&nbsp;<span style="color:blue;">var</span>&nbsp;_)); &nbsp;&nbsp;&nbsp;&nbsp;readerTD &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Setup(r&nbsp;=&gt;&nbsp;r.Lookup(user.Id.ToString())) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Returns(<span style="color:#2b91af;">Result</span>.Success&lt;<span style="color:#2b91af;">User</span>,&nbsp;<span style="color:#2b91af;">IUserLookupError</span>&gt;(user)); &nbsp;&nbsp;&nbsp;&nbsp;readerTD &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Setup(r&nbsp;=&gt;&nbsp;r.Lookup(otherUserId)) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Returns(<span style="color:#2b91af;">Result</span>.Error&lt;<span style="color:#2b91af;">User</span>,&nbsp;<span style="color:#2b91af;">IUserLookupError</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">UserLookupError</span>.InvalidId)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;actual&nbsp;=&nbsp;sut.Post(user.Id.ToString(),&nbsp;otherUserId); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;err&nbsp;=&nbsp;<span style="color:#2b91af;">Assert</span>.IsAssignableFrom&lt;<span style="color:#2b91af;">BadRequestErrorMessageResult</span>&gt;(actual); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(<span style="color:#a31515;">&quot;Invalid&nbsp;ID&nbsp;for&nbsp;other&nbsp;user.&quot;</span>,&nbsp;err.Message); &nbsp;&nbsp;&nbsp;&nbsp;repoTD.Verify(r&nbsp;=&gt;&nbsp;r.Update(<span style="color:#2b91af;">It</span>.IsAny&lt;<span style="color:#2b91af;">User</span>&gt;()),&nbsp;<span style="color:#2b91af;">Times</span>.Never()); }</pre> </p> <p> Notice how the test configures <code>readerTD</code> twice: once for the <code>Id</code> associated with <code>user</code>, and once for <code>otherUserId</code>. Why does this test look different from the previous test? </p> <p> Why is the first <code>Setup</code> required? Couldn't the <em>arrange</em> phase of the test just look like the following? </p> <p> <pre><span style="color:#2b91af;">Assert</span>.False(<span style="color:blue;">int</span>.TryParse(otherUserId,&nbsp;<span style="color:blue;">out</span>&nbsp;<span style="color:blue;">var</span>&nbsp;_)); readerTD &nbsp;&nbsp;&nbsp;&nbsp;.Setup(r&nbsp;=&gt;&nbsp;r.Lookup(otherUserId)) &nbsp;&nbsp;&nbsp;&nbsp;.Returns(<span style="color:#2b91af;">Result</span>.Error&lt;<span style="color:#2b91af;">User</span>,&nbsp;<span style="color:#2b91af;">IUserLookupError</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">UserLookupError</span>.InvalidId));</pre> </p> <p> If you wrote the test like that, it would resemble the previous test (<code>UsersFailToConnectWhenUserIdIsInvalid</code>). The problem, though, is that if you remove the <code>Setup</code> for the valid user, the test fails. </p> <p> This is another example of how the use of interaction-based testing makes the tests brittle. The tests are tightly coupled to the implementation. </p> <h3 id="1d8f30969e8345f394af8f3e1bda37ae"> Missing users test cases <a href="#1d8f30969e8345f394af8f3e1bda37ae" title="permalink">#</a> </h3> <p> I don't want to belabour the point, so here's the two remaining tests: </p> <p> <pre>[<span style="color:#2b91af;">Theory</span>,&nbsp;<span style="color:#2b91af;">UserManagementTestConventions</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;UsersDoNotConnectWhenUserDoesNotExist( &nbsp;&nbsp;&nbsp;&nbsp;[<span style="color:#2b91af;">Frozen</span>]<span style="color:#2b91af;">Mock</span>&lt;<span style="color:#2b91af;">IUserReader</span>&gt;&nbsp;readerTD, &nbsp;&nbsp;&nbsp;&nbsp;[<span style="color:#2b91af;">Frozen</span>]<span style="color:#2b91af;">Mock</span>&lt;<span style="color:#2b91af;">IUserRepository</span>&gt;&nbsp;repoTD, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">string</span>&nbsp;userId, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">User</span>&nbsp;otherUser, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">ConnectionsController</span>&nbsp;sut) { &nbsp;&nbsp;&nbsp;&nbsp;readerTD &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Setup(r&nbsp;=&gt;&nbsp;r.Lookup(userId)) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Returns(<span style="color:#2b91af;">Result</span>.Error&lt;<span style="color:#2b91af;">User</span>,&nbsp;<span style="color:#2b91af;">IUserLookupError</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">UserLookupError</span>.NotFound)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;actual&nbsp;=&nbsp;sut.Post(userId,&nbsp;otherUser.Id.ToString()); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;err&nbsp;=&nbsp;<span style="color:#2b91af;">Assert</span>.IsAssignableFrom&lt;<span style="color:#2b91af;">BadRequestErrorMessageResult</span>&gt;(actual); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(<span style="color:#a31515;">&quot;User&nbsp;not&nbsp;found.&quot;</span>,&nbsp;err.Message); &nbsp;&nbsp;&nbsp;&nbsp;repoTD.Verify(r&nbsp;=&gt;&nbsp;r.Update(<span style="color:#2b91af;">It</span>.IsAny&lt;<span style="color:#2b91af;">User</span>&gt;()),&nbsp;<span style="color:#2b91af;">Times</span>.Never()); } [<span style="color:#2b91af;">Theory</span>,&nbsp;<span style="color:#2b91af;">UserManagementTestConventions</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;UsersDoNotConnectWhenOtherUserDoesNotExist( &nbsp;&nbsp;&nbsp;&nbsp;[<span style="color:#2b91af;">Frozen</span>]<span style="color:#2b91af;">Mock</span>&lt;<span style="color:#2b91af;">IUserReader</span>&gt;&nbsp;readerTD, &nbsp;&nbsp;&nbsp;&nbsp;[<span style="color:#2b91af;">Frozen</span>]<span style="color:#2b91af;">Mock</span>&lt;<span style="color:#2b91af;">IUserRepository</span>&gt;&nbsp;repoTD, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">User</span>&nbsp;user, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;otherUserId, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">ConnectionsController</span>&nbsp;sut) { &nbsp;&nbsp;&nbsp;&nbsp;readerTD &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Setup(r&nbsp;=&gt;&nbsp;r.Lookup(user.Id.ToString())) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Returns(<span style="color:#2b91af;">Result</span>.Success&lt;<span style="color:#2b91af;">User</span>,&nbsp;<span style="color:#2b91af;">IUserLookupError</span>&gt;(user)); &nbsp;&nbsp;&nbsp;&nbsp;readerTD &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Setup(r&nbsp;=&gt;&nbsp;r.Lookup(otherUserId.ToString())) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Returns(<span style="color:#2b91af;">Result</span>.Error&lt;<span style="color:#2b91af;">User</span>,&nbsp;<span style="color:#2b91af;">IUserLookupError</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">UserLookupError</span>.NotFound)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;actual&nbsp;=&nbsp;sut.Post(user.Id.ToString(),&nbsp;otherUserId.ToString()); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;err&nbsp;=&nbsp;<span style="color:#2b91af;">Assert</span>.IsAssignableFrom&lt;<span style="color:#2b91af;">BadRequestErrorMessageResult</span>&gt;(actual); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(<span style="color:#a31515;">&quot;Other&nbsp;user&nbsp;not&nbsp;found.&quot;</span>,&nbsp;err.Message); &nbsp;&nbsp;&nbsp;&nbsp;repoTD.Verify(r&nbsp;=&gt;&nbsp;r.Update(<span style="color:#2b91af;">It</span>.IsAny&lt;<span style="color:#2b91af;">User</span>&gt;()),&nbsp;<span style="color:#2b91af;">Times</span>.Never()); }</pre> </p> <p> Again, notice the asymmetry of these two tests. The top one passes with only one <code>Setup</code> of <code>readerTD</code>, whereas the bottom test requires two in order to pass. </p> <p> You can add a second <code>Setup</code> to the top test to make the two tests equivalent, but people often forget to take such precautions. The result is Fragile Tests. </p> <h3 id="ece9e2b8532f4e7c9e445e9840789121"> Post implementation <a href="#ece9e2b8532f4e7c9e445e9840789121" title="permalink">#</a> </h3> <p> In the spirit of test-driven development, I've shown you the tests before the implementation. </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">ConnectionsController</span>&nbsp;:&nbsp;<span style="color:#2b91af;">ApiController</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;ConnectionsController( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IUserReader</span>&nbsp;userReader, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IUserRepository</span>&nbsp;userRepository) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;UserReader&nbsp;=&nbsp;userReader; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;UserRepository&nbsp;=&nbsp;userRepository; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IUserReader</span>&nbsp;UserReader&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IUserRepository</span>&nbsp;UserRepository&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IHttpActionResult</span>&nbsp;Post(<span style="color:blue;">string</span>&nbsp;userId,&nbsp;<span style="color:blue;">string</span>&nbsp;otherUserId) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;userRes&nbsp;=&nbsp;UserReader.Lookup(userId).SelectError( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;error&nbsp;=&gt;&nbsp;error.Accept(<span style="color:#2b91af;">UserLookupError</span>.Switch( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;onInvalidId:&nbsp;<span style="color:#a31515;">&quot;Invalid&nbsp;user&nbsp;ID.&quot;</span>, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;onNotFound:&nbsp;&nbsp;<span style="color:#a31515;">&quot;User&nbsp;not&nbsp;found.&quot;</span>))); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;otherUserRes&nbsp;=&nbsp;UserReader.Lookup(otherUserId).SelectError( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;error&nbsp;=&gt;&nbsp;error.Accept(<span style="color:#2b91af;">UserLookupError</span>.Switch( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;onInvalidId:&nbsp;<span style="color:#a31515;">&quot;Invalid&nbsp;ID&nbsp;for&nbsp;other&nbsp;user.&quot;</span>, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;onNotFound:&nbsp;&nbsp;<span style="color:#a31515;">&quot;Other&nbsp;user&nbsp;not&nbsp;found.&quot;</span>))); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;connect&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">from</span>&nbsp;user&nbsp;<span style="color:blue;">in</span>&nbsp;userRes &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">from</span>&nbsp;otherUser&nbsp;<span style="color:blue;">in</span>&nbsp;otherUserRes &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">select</span>&nbsp;Connect(user,&nbsp;otherUser); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;connect.SelectBoth(Ok,&nbsp;BadRequest).Bifold(); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:#2b91af;">User</span>&nbsp;Connect(<span style="color:#2b91af;">User</span>&nbsp;user,&nbsp;<span style="color:#2b91af;">User</span>&nbsp;otherUser) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;user.Connect(otherUser); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;UserRepository.Update(user); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;otherUser; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> This is a simplified version of the code shown towards the end of my <a href="https://cleancoders.com/episode/humane-code-real-episode-5/show">Preserved in translation</a> video, so I'll refer you there for a detailed explanation. </p> <h3 id="ed29f1f1efa14245a29e33010c4dd4d1"> Summary <a href="#ed29f1f1efa14245a29e33010c4dd4d1" title="permalink">#</a> </h3> <p> The premise of <a href="http://amzn.to/YPdQDf">Refactoring</a> is that in order to be able to refactor, the "precondition is [...] solid tests". In reality, many development organisations have the opposite experience. When programmers attempt to make changes to how their code is organised, tests break. In <a href="http://bit.ly/xunitpatterns">xUnit Test Patterns</a> this problem is called <em>Fragile Tests</em>, and the cause is often <em>Overspecified Software</em>. This means that tests are tightly coupled to implementation details of the System Under Test (SUT). </p> <p> It's easy to inadvertently fall into this trap when you use Mocks and Stubs, even when you follow the rule of using Mocks for Commands and Stubs for Queries. In my experience, it's often the explicit configuration of Stubs that tend to make tests brittle. A Command represents an intentional side effect, and you want to verify that such a side effect takes place. A Query, on the other hand, has no side effect, so a black-box test shouldn't be concerned with any interactions involving Queries. </p> <p> Yet, using an 'isolation framework' such as Moq, <a href="https://fakeiteasy.github.io/">FakeItEasy</a>, <a href="http://nsubstitute.github.io/">NSubstitute</a>, and so on, will pull you towards overspecifying the interactions the SUT has with its Query dependencies. </p> <p> How can we improve? One strategy is to move towards a more functional design, which is <a href="/2015/05/07/functional-design-is-intrinsically-testable">intrinsically testable</a>. In the next article, you'll see how to rewrite both tests and implementation in <a href="https://www.haskell.org">Haskell</a>. </p> <p> <strong>Next:</strong> <a href="/2019/03/11/an-example-of-state-based-testing-in-haskell">An example of state-based testing in Haskell</a>. </p> </div> <div id="comments"> <hr> <h2 id="comments-header"> Comments </h2> <div class="comment"> <div class="comment-author"><a href="https://remibou.github.io/">Rémi Bourgarel</a></div> <div class="comment-content"> <p> Hi Mark, </p> <p> I think I came to the same conclusion (maybe not the same solution), meaning you can't write solid tests when mocking all the dependencies interaction : all these dependencies interaction are implementation details (even the database system you chose). For writing solid tests I chose to write my tests like this : start all the services I can in test environment (database, queue ...), mock only things I have no choice (external PSP or Google Captcha), issue command (using MediatR) and check the result with a query. You can find some of my work <a href="https://github.com/RemiBou/Toss.Blazor/blob/master/Toss.Tests/Server/Models/Tosses/LastTossQueryHandlerTest.cs"> here </a>. The work is not done on all the tests but this is the way I want to go. Let me know what you think about it. </p> <p> I could have launched the tests at the Controller level but I chose Command and Query handler.</p> <p> Can't wait to see your solution </p> </div> <div class="comment-date">2019-02-25 07:53 UTC</div> </div> <div class="comment" id="7b60769bf7eb4be3969623d4819d5c0e"> <div class="comment-author"><a href="/">Mark Seemann</a></div> <div class="comment-content"> <p> Rémi, thank you for writing. Hosting services as part of a test run can be a valuable addition to an overall testing or release pipeline. It's reminiscent of the approach taken in <a href="http://bit.ly/growingoos">GOOS</a>. I've also touched on this option in my Pluralsight course <a href="https://blog.ploeh.dk/outside-in-tdd">Outside-In Test-Driven Development</a>. This is, however, a set of tests I would identify as belonging towards the top of a <a href="https://martinfowler.com/bliki/TestPyramid.html">Test Pyramid</a>. In my experience, such tests tend to run (an order of magnitude) slower than unit tests. </p> <p> That doesn't preclude their use. Depending on circumstances, I still prefer having tests like that. I think that I've written a few applications where tests like that constituted the main body of unit tests. </p> <p> I do, however, also find this style of testing too limiting in many situation. I tend to prefer 'real' unit tests, since they tend to be easier to write, and they execute faster. </p> <p> Apart from performance and maintainability concerns, one problem that I often see with integration tests is that <a href="https://www.infoq.com/presentations/integration-tests-scam">it's practically impossible to cover all edge cases</a>. This tends to lead to either bug-ridden software, or unmaintainable test suites. </p> <p> Still, I think that, ultimately, having enough experience with different styles of testing enables one to make an informed choice. That's my purpose with these articles: to point out that alternatives exist. </p> </div> <div class="comment-date">2019-03-01 9:31 UTC</div> </div> </div> <hr> This blog is totally free, but if you like it, please consider <a href="https://blog.ploeh.dk/support">supporting it</a>. Mark Seemann https://blog.ploeh.dk/2019/02/25/an-example-of-interaction-based-testing-in-c From interaction-based to state-based testing https://blog.ploeh.dk/2019/02/18/from-interaction-based-to-state-based-testing/ Mon, 18 Feb 2019 08:19:00 UTC <div id="post"> <p> <em>Indiscriminate use of Mocks and Stubs can lead to brittle test suites. A more functional design can make state-based testing easier, leading to more robust test suites.</em> </p> <p> The original premise of <a href="http://amzn.to/YPdQDf">Refactoring</a> was that in order to refactor, you must have a trustworthy suite of unit tests, so that you can be confident that you didn't break any functionality. <blockquote> <p>"to refactor, the essential precondition is [...] solid tests"</p> <footer><cite>Martin Fowler, <a href="http://amzn.to/YPdQDf">Refactoring</a></cite></footer> </blockquote> The idea is that you can change how the code is organised, and as long as you don't break any tests, all is good. The experience that most people seem to have, though, is that when they change something in the code, tests break. </p> <p> This is a well-known test smell. In <a href="http://bit.ly/xunitpatterns">xUnit Test Patterns</a> this is called <em>Fragile Test</em>, and it's often caused by <em>Overspecified Software</em>. Even if you follow the proper practice of using <a href="/2013/10/23/mocks-for-commands-stubs-for-queries">Mocks for Commands, Stubs for Queries</a>, you can still end up with a code base where the tests are highly coupled to implementation details of the software. </p> <p> The cause is often that when relying on Mocks and Stubs, test verification hinges on how the System Under Test (SUT) interacts with its dependencies. For that reason, we can call such tests <em>interaction-based tests</em>. For more information, watch my Pluralsight course <a href="https://blog.ploeh.dk/advanced-unit-testing">Advanced Unit Testing</a>. </p> <h3 id="fb4f2eb1191943c09450c7281a6c8cb0"> Lessons from functional programming <a href="#fb4f2eb1191943c09450c7281a6c8cb0" title="permalink">#</a> </h3> <p> Another way to verify the outcome of a test is to inspect the state of the system after exercising the SUT. We can, quite naturally, call this <em>state-based testing</em>. In object-oriented design, this can lead to other problems. <a href="http://natpryce.com">Nat Pryce</a> has pointed out that <a href="http://natpryce.com/articles/000342.html">state-based testing breaks encapsulation</a>. </p> <p> Interestingly, in his article, Nat Pryce concludes: <blockquote> "I have come to think of object oriented programming as an inversion of functional programming. In a lazy functional language data is pulled through functions that transform the data and combine it into a single result. In an object oriented program, data is pushed out in messages to objects that transform the data and push it out to other objects for further processing." </blockquote> That's an impressively perceptive observation to make in 2004. I wish I was that perspicacious, but I only <a href="https://blog.ploeh.dk/functional-architecture-with-fsharp">reached a similar conclusion ten years later</a>. </p> <p> Functional programming is based on the fundamental principle of <a href="https://en.wikipedia.org/wiki/Referential_transparency">referential transparency</a>, which, among other things, means that data must be immutable. Thus, no objects change state. Instead, functions can return data that contains immutable state. In unit tests, you can verify that return values are as expected. <a href="/2015/05/07/functional-design-is-intrinsically-testable">Functional design is intrinsically testable</a>; we can consider it a kind of state-based testing, although the states you'd be verifying are immutable return values. </p> <p> In this article series, you'll see three different styles of testing, from interaction-based testing with Mocks and Stubs in C#, over strictly functional state-based testing in <a href="https://www.haskell.org">Haskell</a>, to pragmatic state-based testing in <a href="https://fsharp.org">F#</a>, finally looping back to C# to apply the lessons from functional programming. <ul> <li><a href="/2019/02/25/an-example-of-interaction-based-testing-in-c">An example of interaction-based testing in C#</a></li> <li><a href="/2019/03/11/an-example-of-state-based-testing-in-haskell">An example of state-based testing in Haskell</a></li> <li><a href="/2019/03/25/an-example-of-state-based-testing-in-f">An example of state based-testing in F#</a></li> <li>An example of state based-testing in C#</li> </ul> The code for all of these articles is <a href="https://github.com/ploeh/UserManagement">available on GitHub</a>. </p> <h3 id="d370a0ae3bc34440b68f8fddab6c1b25"> Summary <a href="#d370a0ae3bc34440b68f8fddab6c1b25" title="permalink">#</a> </h3> <p> Adopting a more functional design, even in a fundamentally object-oriented language like C# can, in my experience, lead to a more sustainable code base. Various maintenance tasks become easier, including unit tests. Functional programming, however, is no panacea. My intent with this article series is only to inspire; to show alternatives to the ways things are normally done. Adopting one of those alternatives could lead to better code, but you must still exercise context-specific judgement. </p> <p> <strong>Next:</strong> <a href="/2019/02/25/an-example-of-interaction-based-testing-in-c">An example of interaction-based testing in C#</a>. </p> </div><hr> This blog is totally free, but if you like it, please consider <a href="https://blog.ploeh.dk/support">supporting it</a>. Mark Seemann https://blog.ploeh.dk/2019/02/18/from-interaction-based-to-state-based-testing Asynchronous Injection https://blog.ploeh.dk/2019/02/11/asynchronous-injection/ Mon, 11 Feb 2019 07:43:00 UTC <div id="post"> <p> <em>How to combine asynchronous programming with Dependency Injection without leaky abstractions.</em> </p> <p> C# has decent support for asynchronous programming, but it ultimately leads to leaky abstractions. This is often conspicuous when combined with Dependency Injection (DI). This leads to frequently asked questions around the combination of DI and asynchronous programming. This article outlines the problem and suggests an alternative. </p> <p> The code base supporting this article is <a href="https://github.com/ploeh/asynchronous-injection">available on GitHub</a>. </p> <h3 id="0463aa2fd41b46bbbb837709ed9bc58b"> A synchronous example <a href="#0463aa2fd41b46bbbb837709ed9bc58b" title="permalink">#</a> </h3> <p> In this article, you'll see various stages of a small sample code base that pretends to implement the server-side behaviour of an on-line restaurant reservation system (my favourite example scenario). In the first stage, the code uses DI, but no asynchronous I/O. </p> <p> At the boundary of the application, a <code>Post</code> method receives a <code>Reservation</code> object: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">ReservationsController</span>&nbsp;:&nbsp;<span style="color:#2b91af;">ControllerBase</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;ReservationsController(<span style="color:#2b91af;">IMaîtreD</span>&nbsp;maîtreD) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MaîtreD&nbsp;=&nbsp;maîtreD; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IMaîtreD</span>&nbsp;MaîtreD&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IActionResult</span>&nbsp;Post(<span style="color:#2b91af;">Reservation</span>&nbsp;reservation) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>?&nbsp;id&nbsp;=&nbsp;MaîtreD.TryAccept(reservation); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(id&nbsp;==&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;InternalServerError(<span style="color:#a31515;">&quot;Table&nbsp;unavailable&quot;</span>); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;Ok(id.Value); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> The <code>Reservation</code> object is just a simple bundle of properties: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Reservation</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;Date&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">string</span>&nbsp;Email&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">string</span>&nbsp;Name&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">int</span>&nbsp;Quantity&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">bool</span>&nbsp;IsAccepted&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} }</pre> </p> <p> In a production code base, I'd favour a separation of <a href="https://en.wikipedia.org/wiki/Data_transfer_object">DTOs</a> and domain objects with proper encapsulation, but in order to keep the code example simple, here the two roles are combined. </p> <p> The <code>Post</code> method simply delegates most work to an injected <code>IMaîtreD</code> object, and translates the return value to an HTTP response. </p> <p> The code example is overly simplistic, to the point where you may wonder what is the point of DI, since it seems that the <code>Post</code> method doesn't perform any work itself. A slightly <a href="/2017/01/27/dependency-injection-is-passing-an-argument">more realistic example includes some input validation and mapping between layers</a>. </p> <p> The <code>IMaîtreD</code> implementation is this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MaîtreD</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IMaîtreD</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;MaîtreD(<span style="color:blue;">int</span>&nbsp;capacity,&nbsp;<span style="color:#2b91af;">IReservationsRepository</span>&nbsp;repository) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Capacity&nbsp;=&nbsp;capacity; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Repository&nbsp;=&nbsp;repository; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">int</span>&nbsp;Capacity&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IReservationsRepository</span>&nbsp;Repository&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">int</span>?&nbsp;TryAccept(<span style="color:#2b91af;">Reservation</span>&nbsp;reservation) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;reservations&nbsp;=&nbsp;Repository.ReadReservations(reservation.Date); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;reservedSeats&nbsp;=&nbsp;reservations.Sum(r&nbsp;=&gt;&nbsp;r.Quantity); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(Capacity&nbsp;&lt;&nbsp;reservedSeats&nbsp;+&nbsp;reservation.Quantity) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">null</span>; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;reservation.IsAccepted&nbsp;=&nbsp;<span style="color:blue;">true</span>; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;Repository.Create(reservation); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> The protocol for the <code>TryAccept</code> method is that it returns the reservation ID if it accepts the reservation. If the restaurant has too little remaining <code>Capacity</code> for the requested date, it instead returns <code>null</code>. Regular readers of this blog will know that I'm <a href="/2015/11/13/null-has-no-type-but-maybe-has">no fan of null</a>, but this keeps the example realistic. I'm also no fan of state mutation, but the example does that as well, by setting <code>IsAccepted</code> to <code>true</code>. </p> <h3 id="fa919e35f82a4387822c9888dd5d7537"> Introducing asynchrony <a href="#fa919e35f82a4387822c9888dd5d7537" title="permalink">#</a> </h3> <p> The above example is entirely synchronous, but perhaps you wish to introduce some asynchrony. For example, the <code>IReservationsRepository</code> implies synchrony: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IReservationsRepository</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Reservation</span>[]&nbsp;ReadReservations(<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;date); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;Create(<span style="color:#2b91af;">Reservation</span>&nbsp;reservation); }</pre> </p> <p> In reality, though, you know that the implementation of this interface queries and writes to a relational database. Perhaps making this communication asynchronous could improve application performance. It's worth a try, at least. </p> <p> How do you make something asynchronous in C#? You change the return type of the methods in question. Therefore, you have to change the <code>IReservationsRepository</code> interface: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IReservationsRepository</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Task</span>&lt;<span style="color:#2b91af;">Reservation</span>[]&gt;&nbsp;ReadReservations(<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;date); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Task</span>&lt;<span style="color:blue;">int</span>&gt;&nbsp;Create(<span style="color:#2b91af;">Reservation</span>&nbsp;reservation); }</pre> </p> <p> The Repository methods now return Tasks. This is the first leaky abstraction. From the <a href="http://en.wikipedia.org/wiki/Dependency_inversion_principle">Dependency Inversion Principle</a> it follows that <blockquote> <p>"clients [...] own the abstract interfaces"</p> <footer><cite>Robert C. Martin, <a href="http://amzn.to/19W4JHk">APPP</a>, chapter 11</cite></footer> </blockquote> The <code>MaîtreD</code> class is the client of the <code>IReservationsRepository</code> interface, which should be designed to support the needs of that class. <code>MaîtreD</code> doesn't need <code>IReservationsRepository</code> to be asynchronous. </p> <p> The change of the interface has nothing to with what <code>MaîtreD</code> needs, but rather with a particular implementation of the <code>IReservationsRepository</code> interface. Because this implementation queries and writes to a relational database, this implementation detail leaks into the interface definition. It is, therefore, a leaky abstraction. </p> <p> On a more practical level, accommodating the change is easily done. Just add <code>async</code> and <code>await</code> keywords in appropriate places: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">async</span>&nbsp;<span style="color:#2b91af;">Task</span>&lt;<span style="color:blue;">int</span>?&gt;&nbsp;TryAccept(<span style="color:#2b91af;">Reservation</span>&nbsp;reservation) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;reservations&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">await</span>&nbsp;Repository.ReadReservations(reservation.Date); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;reservedSeats&nbsp;=&nbsp;reservations.Sum(r&nbsp;=&gt;&nbsp;r.Quantity); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(Capacity&nbsp;&lt;&nbsp;reservedSeats&nbsp;+&nbsp;reservation.Quantity) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">null</span>; &nbsp;&nbsp;&nbsp;&nbsp;reservation.IsAccepted&nbsp;=&nbsp;<span style="color:blue;">true</span>; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">await</span>&nbsp;Repository.Create(reservation); }</pre> </p> <p> In order to compile, however, you also have to fix the <code>IMaîtreD</code> interface: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IMaîtreD</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Task</span>&lt;<span style="color:blue;">int</span>?&gt;&nbsp;TryAccept(<span style="color:#2b91af;">Reservation</span>&nbsp;reservation); }</pre> </p> <p> This is the second leaky abstraction, and it's worse than the first. Perhaps you could successfully argue that it was conceptually acceptable to model <code>IReservationsRepository</code> as asynchronous. After all, a Repository conceptually represents a data store, and these are generally out-of-process resources that require I/O. </p> <p> The <code>IMaîtreD</code> interface, on the other hand, is a domain object. It models how business is done, not how data should be accessed. Why should business logic be asynchronous? </p> <p> It's hardly news that <a href="http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/">async and await is infectious</a>. Once you introduce Tasks, it's <em>async all the way!</em> </p> <p> That doesn't mean that asynchrony isn't one big leaky abstraction. It is. </p> <p> You've probably already realised what this means in the context of the little example. You must also patch the <code>Post</code> method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">async</span>&nbsp;<span style="color:#2b91af;">Task</span>&lt;<span style="color:#2b91af;">IActionResult</span>&gt;&nbsp;Post(<span style="color:#2b91af;">Reservation</span>&nbsp;reservation) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>?&nbsp;id&nbsp;=&nbsp;<span style="color:blue;">await</span>&nbsp;MaîtreD.TryAccept(reservation); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(id&nbsp;==&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;InternalServerError(<span style="color:#a31515;">&quot;Table&nbsp;unavailable&quot;</span>); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;Ok(id.Value); }</pre> </p> <p> Pragmatically, I'd be ready to accept the argument that this isn't a big deal. After all, you just replace all return values with Tasks, and add <code>async</code> and <code>await</code> keywords where they need to go. This hardly impacts the maintainability of a code base. </p> <p> In C#, I'd be inclined to just acknowledge that, <em>hey, there's a leaky abstraction. Moving on...</em> </p> <p> On the other hand, sometimes people imply that it has to be like this. That there is no other way. </p> <p> <a href="https://en.wikipedia.org/wiki/Falsifiability">Falsifiable claims</a> like that often get my attention. <em>Oh, really?!</em> </p> <h3 id="46df3267f63a4c908ed710c2b4f9d3f9"> Move impure interactions to the boundary of the system <a href="#46df3267f63a4c908ed710c2b4f9d3f9" title="permalink">#</a> </h3> <p> We can <a href="/2018/09/24/asynchronous-functors">pretend that <code>Task&lt;T&gt;</code> forms a functor</a>. It's also a monad. Monads are those incredibly useful programming abstractions that have been propagating from their origin in statically typed functional programming languages to more mainstream languages like C#. </p> <p> In functional programming, <a href="/2016/03/18/functional-architecture-is-ports-and-adapters">impure interactions happen at the boundary of the system</a>. Taking inspiration from functional programming, you can <a href="/2017/01/27/from-dependency-injection-to-dependency-rejection">move the impure interactions to the boundary of the system</a>. </p> <p> In the interest of keeping the example simple, I'll only move the impure operations one level out: from <code>MaîtreD</code> to <code>ReservationsController</code>. The approach can be generalised, although you may have to look into how to handle <a href="/2017/07/10/pure-interactions">pure interactions</a>. </p> <p> Where are the impure interactions in <code>MaîtreD</code>? They are in the two interactions with <code>IReservationsRepository</code>. The <code>ReadReservations</code> method is non-deterministic, because the same input value can return different results, depending on the state of the database when you call it. The <code>Create</code> method causes a side effect to happen, because it creates a row in the database. This is one way in which the state of the database could change, which makes <code>ReadReservations</code> non-deterministic. Additionally, <code>Create</code> also violates <a href="https://en.wikipedia.org/wiki/Command%E2%80%93query_separation">Command Query Separation</a> (CQS) by returning the ID of the row it creates. This, again, is non-deterministic, because the same input value will produce a new return value every time the method is called. (Incidentally, you should <a href="/2014/08/11/cqs-versus-server-generated-ids">design <code>Create</code> methods so that they don't violate CQS</a>.) </p> <h3 id="dea3b9778dd54d6c9b18e9b3e9c95153"> Move reservations to a method argument <a href="#dea3b9778dd54d6c9b18e9b3e9c95153" title="permalink">#</a> </h3> <p> The first refactoring is the easiest. Move the <code>ReadReservations</code> method call to the application boundary. In the above state of the code, the <code>TryAccept</code> method unconditionally calls <code>Repository.ReadReservations</code> to populate the <code>reservations</code> variable. Instead of doing this from within <code>TryAccept</code>, just pass <code>reservations</code> as a method argument: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">async</span>&nbsp;<span style="color:#2b91af;">Task</span>&lt;<span style="color:blue;">int</span>?&gt;&nbsp;TryAccept( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Reservation</span>[]&nbsp;reservations, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Reservation</span>&nbsp;reservation) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;reservedSeats&nbsp;=&nbsp;reservations.Sum(r&nbsp;=&gt;&nbsp;r.Quantity); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(Capacity&nbsp;&lt;&nbsp;reservedSeats&nbsp;+&nbsp;reservation.Quantity) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">null</span>; &nbsp;&nbsp;&nbsp;&nbsp;reservation.IsAccepted&nbsp;=&nbsp;<span style="color:blue;">true</span>; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">await</span>&nbsp;Repository.Create(reservation); }</pre> </p> <p> This no longer compiles until you also change the <code>IMaîtreD</code> interface: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IMaîtreD</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Task</span>&lt;<span style="color:blue;">int</span>?&gt;&nbsp;TryAccept(<span style="color:#2b91af;">Reservation</span>[]&nbsp;reservations,&nbsp;<span style="color:#2b91af;">Reservation</span>&nbsp;reservation); }</pre> </p> <p> You probably think that this is a much worse leaky abstraction than returning a Task. I'd be inclined to agree, but trust me: ultimately, this will matter not at all. </p> <p> When you move an impure operation outwards, it means that when you remove it from one place, you must add it to another. In this case, you'll have to query the Repository from the <code>ReservationsController</code>, which also means that you need to add the Repository as a dependency there: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">ReservationsController</span>&nbsp;:&nbsp;<span style="color:#2b91af;">ControllerBase</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;ReservationsController( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IMaîtreD</span>&nbsp;maîtreD, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IReservationsRepository</span>&nbsp;repository) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MaîtreD&nbsp;=&nbsp;maîtreD; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Repository&nbsp;=&nbsp;repository; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IMaîtreD</span>&nbsp;MaîtreD&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IReservationsRepository</span>&nbsp;Repository&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">async</span>&nbsp;<span style="color:#2b91af;">Task</span>&lt;<span style="color:#2b91af;">IActionResult</span>&gt;&nbsp;Post(<span style="color:#2b91af;">Reservation</span>&nbsp;reservation) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;reservations&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">await</span>&nbsp;Repository.ReadReservations(reservation.Date); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>?&nbsp;id&nbsp;=&nbsp;<span style="color:blue;">await</span>&nbsp;MaîtreD.TryAccept(reservations,&nbsp;reservation); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(id&nbsp;==&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;InternalServerError(<span style="color:#a31515;">&quot;Table&nbsp;unavailable&quot;</span>); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;Ok(id.Value); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> This is a refactoring in the true sense of the word. It just reorganises the code without changing the overall behaviour of the system. Now the <code>Post</code> method has to query the Repository before it can delegate the business decision to <code>MaîtreD</code>. </p> <h3 id="6a492b66a0d14edda105eb3fb3b4ebb4"> Separate decision from effect <a href="#6a492b66a0d14edda105eb3fb3b4ebb4" title="permalink">#</a> </h3> <p> As far as I can tell, the main reason to use DI is because some impure interactions are conditional. This is also the case for the <code>TryAccept</code> method. Only if there's sufficient remaining capacity does it call <code>Repository.Create</code>. If it detects that there's too little remaining capacity, it immediately returns <code>null</code> and doesn't call <code>Repository.Create</code>. </p> <p> In object-oriented code, DI is the most common way to decouple decisions from effects. Imperative code reaches a decision and calls a method on an object based on that decision. The effect of calling the method can vary because of polymorphism. </p> <p> In functional programming, you typically use a <a href="/2018/03/22/functors">functor</a> like <a href="/2018/03/26/the-maybe-functor">Maybe</a> or <a href="/2018/06/11/church-encoded-either">Either</a> to <a href="/2016/09/26/decoupling-decisions-from-effects">separate decisions from effects</a>. You can do the same here. </p> <p> The protocol of the <code>TryAccept</code> method already communicates the decision reached by the method. An <code>int</code> value is the reservation ID; this implies that the reservation was accepted. On the other hand, <code>null</code> indicates that the reservation was declined. </p> <p> You can use the same sort of protocol, but instead of returning a <code>Nullable&lt;int&gt;</code>, you can return a <code>Maybe&lt;Reservation&gt;</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">async</span>&nbsp;<span style="color:#2b91af;">Task</span>&lt;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">Reservation</span>&gt;&gt;&nbsp;TryAccept( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Reservation</span>[]&nbsp;reservations, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Reservation</span>&nbsp;reservation) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;reservedSeats&nbsp;=&nbsp;reservations.Sum(r&nbsp;=&gt;&nbsp;r.Quantity); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(Capacity&nbsp;&lt;&nbsp;reservedSeats&nbsp;+&nbsp;reservation.Quantity) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:#2b91af;">Maybe</span>.Empty&lt;<span style="color:#2b91af;">Reservation</span>&gt;(); &nbsp;&nbsp;&nbsp;&nbsp;reservation.IsAccepted&nbsp;=&nbsp;<span style="color:blue;">true</span>; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;reservation.ToMaybe(); }</pre> </p> <p> This completely decouples the decision from the effect. By returning <code>Maybe&lt;Reservation&gt;</code>, the <code>TryAccept</code> method communicates the decision it made, while leaving further processing entirely up to the caller. </p> <p> In this case, the caller is the <code>Post</code> method, which can now compose the result of invoking <code>TryAccept</code> with <code>Repository.Create</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">async</span>&nbsp;<span style="color:#2b91af;">Task</span>&lt;<span style="color:#2b91af;">IActionResult</span>&gt;&nbsp;Post(<span style="color:#2b91af;">Reservation</span>&nbsp;reservation) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;reservations&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">await</span>&nbsp;Repository.ReadReservations(reservation.Date); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">Reservation</span>&gt;&nbsp;m&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">await</span>&nbsp;MaîtreD.TryAccept(reservations,&nbsp;reservation); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">await</span>&nbsp;m &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Select(<span style="color:blue;">async</span>&nbsp;r&nbsp;=&gt;&nbsp;<span style="color:blue;">await</span>&nbsp;Repository.Create(r)) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Match( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;nothing:&nbsp;<span style="color:#2b91af;">Task</span>.FromResult(InternalServerError(<span style="color:#a31515;">&quot;Table&nbsp;unavailable&quot;</span>)), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;just:&nbsp;<span style="color:blue;">async</span>&nbsp;id&nbsp;=&gt;&nbsp;Ok(<span style="color:blue;">await</span>&nbsp;id)); }</pre> </p> <p> Notice that the <code>Post</code> method never attempts to <a href="/2019/02/04/how-to-get-the-value-out-of-the-monad">extract 'the value' from <code>m</code></a>. Instead, it injects the desired behaviour (<code>Repository.Create</code>) into the monad. The result of calling <code>Select</code> with an asynchronous lambda expression like that is a <code>Maybe&lt;Task&lt;int&gt;&gt;</code>, which is a awkward combination. You can fix that later. </p> <p> The <code>Match</code> method is the catamorphism for Maybe. It looks exactly like the <code>Match</code> method on the <a href="/2018/06/04/church-encoded-maybe">Church-encoded Maybe</a>. It handles both the case when <code>m</code> is empty, and the case when <code>m</code> is populated. In both cases, it returns a <code>Task&lt;IActionResult&gt;</code>. </p> <h3 id="cfd87db1b9304255bda17d1da93c32ee"> Synchronous domain logic <a href="#cfd87db1b9304255bda17d1da93c32ee" title="permalink">#</a> </h3> <p> At this point, you have a compiler warning in your code: <blockquote> Warning CS1998 This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread. </blockquote> Indeed, the current incarnation of <code>TryAccept</code> is synchronous, so remove the <code>async</code> keyword and change the return type: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">Reservation</span>&gt;&nbsp;TryAccept( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Reservation</span>[]&nbsp;reservations, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Reservation</span>&nbsp;reservation) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;reservedSeats&nbsp;=&nbsp;reservations.Sum(r&nbsp;=&gt;&nbsp;r.Quantity); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(Capacity&nbsp;&lt;&nbsp;reservedSeats&nbsp;+&nbsp;reservation.Quantity) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:#2b91af;">Maybe</span>.Empty&lt;<span style="color:#2b91af;">Reservation</span>&gt;(); &nbsp;&nbsp;&nbsp;&nbsp;reservation.IsAccepted&nbsp;=&nbsp;<span style="color:blue;">true</span>; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;reservation.ToMaybe(); }</pre> </p> <p> This requires a minimal change to the <code>Post</code> method: it no longer has to <code>await</code> <code>TryAccept</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">async</span>&nbsp;<span style="color:#2b91af;">Task</span>&lt;<span style="color:#2b91af;">IActionResult</span>&gt;&nbsp;Post(<span style="color:#2b91af;">Reservation</span>&nbsp;reservation) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;reservations&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">await</span>&nbsp;Repository.ReadReservations(reservation.Date); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">Reservation</span>&gt;&nbsp;m&nbsp;=&nbsp;MaîtreD.TryAccept(reservations,&nbsp;reservation); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">await</span>&nbsp;m &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Select(<span style="color:blue;">async</span>&nbsp;r&nbsp;=&gt;&nbsp;<span style="color:blue;">await</span>&nbsp;Repository.Create(r)) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Match( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;nothing:&nbsp;<span style="color:#2b91af;">Task</span>.FromResult(InternalServerError(<span style="color:#a31515;">&quot;Table&nbsp;unavailable&quot;</span>)), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;just:&nbsp;<span style="color:blue;">async</span>&nbsp;id&nbsp;=&gt;&nbsp;Ok(<span style="color:blue;">await</span>&nbsp;id)); }</pre> </p> <p> Apart from that, this version of <code>Post</code> is the same as the one above. </p> <p> Notice that at this point, the domain logic (<code>TryAccept</code>) is no longer asynchronous. The leaky abstraction is gone. </p> <h3 id="da9febf381b1483883423b96c5ceb9a3"> Redundant abstraction <a href="#da9febf381b1483883423b96c5ceb9a3" title="permalink">#</a> </h3> <p> The overall work is done, but there's some tidying up remaining. If you review the <code>TryAccept</code> method, you'll notice that it no longer uses the injected <code>Repository</code>. You might as well simplify the class by removing the dependency: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MaîtreD</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IMaîtreD</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;MaîtreD(<span style="color:blue;">int</span>&nbsp;capacity) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Capacity&nbsp;=&nbsp;capacity; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">int</span>&nbsp;Capacity&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">Reservation</span>&gt;&nbsp;TryAccept( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Reservation</span>[]&nbsp;reservations, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Reservation</span>&nbsp;reservation) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;reservedSeats&nbsp;=&nbsp;reservations.Sum(r&nbsp;=&gt;&nbsp;r.Quantity); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(Capacity&nbsp;&lt;&nbsp;reservedSeats&nbsp;+&nbsp;reservation.Quantity) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:#2b91af;">Maybe</span>.Empty&lt;<span style="color:#2b91af;">Reservation</span>&gt;(); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;reservation.IsAccepted&nbsp;=&nbsp;<span style="color:blue;">true</span>; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;reservation.ToMaybe(); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> The <code>TryAccept</code> method is now deterministic. The same input will always return the same input. This is not yet a <a href="https://en.wikipedia.org/wiki/Pure_function">pure function</a>, because it still has a single side effect: it mutates the state of <code>reservation</code> by setting <code>IsAccepted</code> to <code>true</code>. You could, however, without too much trouble refactor <code>Reservation</code> to an immutable <a href="https://en.wikipedia.org/wiki/Value_object">Value Object</a>. </p> <p> This would enable you to write the last part of the <code>TryAccept</code> method like this: </p> <p> <pre><span style="color:blue;">return</span>&nbsp;reservation.Accept().ToMaybe();</pre> </p> <p> In any case, the method is close enough to be <a href="/2015/05/07/functional-design-is-intrinsically-testable">pure that it's testable</a>. The interactions of <code>TryAccept</code> and any client code (including unit tests) is completely controllable and observable by the client. </p> <p> This means that there's no reason to <a href="/2013/10/23/mocks-for-commands-stubs-for-queries">Stub it out</a>. You might as well just use the function directly in the <code>Post</code> method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">ReservationsController</span>&nbsp;:&nbsp;<span style="color:#2b91af;">ControllerBase</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;ReservationsController( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;capacity, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IReservationsRepository</span>&nbsp;repository) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Capacity&nbsp;=&nbsp;capacity; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Repository&nbsp;=&nbsp;repository; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">int</span>&nbsp;Capacity&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IReservationsRepository</span>&nbsp;Repository&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">async</span>&nbsp;<span style="color:#2b91af;">Task</span>&lt;<span style="color:#2b91af;">IActionResult</span>&gt;&nbsp;Post(<span style="color:#2b91af;">Reservation</span>&nbsp;reservation) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;reservations&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">await</span>&nbsp;Repository.ReadReservations(reservation.Date); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">Reservation</span>&gt;&nbsp;m&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MaîtreD</span>(Capacity).TryAccept(reservations,&nbsp;reservation); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">await</span>&nbsp;m &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Select(<span style="color:blue;">async</span>&nbsp;r&nbsp;=&gt;&nbsp;<span style="color:blue;">await</span>&nbsp;Repository.Create(r)) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Match( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;nothing:&nbsp;<span style="color:#2b91af;">Task</span>.FromResult(InternalServerError(<span style="color:#a31515;">&quot;Table&nbsp;unavailable&quot;</span>)), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;just:&nbsp;<span style="color:blue;">async</span>&nbsp;id&nbsp;=&gt;&nbsp;Ok(<span style="color:blue;">await</span>&nbsp;id)); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Notice that <code>ReservationsController</code> no longer has an <code>IMaîtreD</code> dependency. </p> <p> All this time, whenever you make a change to the <code>TryAccept</code> method signature, you'd also have to fix the <code>IMaîtreD</code> interface to make the code compile. If you worried that all of these changes were leaky abstractions, you'll be happy to learn that <a href="https://amzn.to/2PzDpJu">in the end, it doesn't even matter</a>. No code uses that interface, so you can delete it. </p> <h3 id="843e56ff0b74406eb236bebd2fad4828"> Grooming <a href="#843e56ff0b74406eb236bebd2fad4828" title="permalink">#</a> </h3> <p> The <code>MaîtreD</code> class looks fine, but the <code>Post</code> method could use some grooming. I'm not going to tire you with all the small refactoring steps. You can follow them in the GitHub repository if you're interested. Eventually, you could arrive at an implementation like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">ReservationsController</span>&nbsp;:&nbsp;<span style="color:#2b91af;">ControllerBase</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;ReservationsController( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;capacity, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IReservationsRepository</span>&nbsp;repository) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Capacity&nbsp;=&nbsp;capacity; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Repository&nbsp;=&nbsp;repository; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;maîtreD&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MaîtreD</span>(capacity); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">int</span>&nbsp;Capacity&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IReservationsRepository</span>&nbsp;Repository&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">MaîtreD</span>&nbsp;maîtreD; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">async</span>&nbsp;<span style="color:#2b91af;">Task</span>&lt;<span style="color:#2b91af;">IActionResult</span>&gt;&nbsp;Post(<span style="color:#2b91af;">Reservation</span>&nbsp;reservation) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">await</span>&nbsp;Repository.ReadReservations(reservation.Date) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Select(rs&nbsp;=&gt;&nbsp;maîtreD.TryAccept(rs,&nbsp;reservation)) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.SelectMany(m&nbsp;=&gt;&nbsp;m.Traverse(Repository.Create)) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Match(InternalServerError(<span style="color:#a31515;">&quot;Table&nbsp;unavailable&quot;</span>),&nbsp;Ok); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Now the <code>Post</code> method is just a single, composed asynchronous pipeline. Is it a coincidence that this is possible? </p> <p> This is no coincidence. This top-level method executes in the 'Task monad', and a monad is, by definition, composable. You can chain operations together, and they don't all have to be asynchronous. Specifically, <code>maîtreD.TryAccept</code> is a synchronous piece of business logic. It's unaware that it's being injected into an asynchronous context. This type of design would be completely run of the mill in <a href="https://fsharp.org">F#</a> with its <a href="https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/asynchronous-workflows">asynchronous workflows</a>. </p> <h3 id="ff3eb0a846d24e1b82291004b5acf126"> Summary <a href="#ff3eb0a846d24e1b82291004b5acf126" title="permalink">#</a> </h3> <p> Dependency Injection frequently involves I/O-bound operations. Those typically get hidden behind interfaces so that they can be mocked or stubbed. You may want to access those I/O-bound resources asynchronously, but with C#'s support for asynchronous programming, you'll have to make your abstractions asynchronous. </p> <p> When you make the leaf nodes in your call graph asynchronous, that design change ripples through the entire code base, forcing you to be <em>async all the way</em>. One result of this is that the domain model must also accommodate asynchrony, although this is rarely required by the logic it implements. These concessions to asynchrony are leaky abstractions. </p> <p> Pragmatically, it's hardly a big problem. You can use the <code>async</code> and <code>await</code> keywords to deal with the asynchrony, and it's unlikely to, in itself, cause a problem with maintenance. </p> <p> In functional programming, monads can address asynchrony without introducing sweeping leaky abstractions. Instead of making DI asynchronous, you can inject desired behaviour into an asynchronous context. </p> <p> Behaviour Injection, not Dependency Injection. </p> </div> <div id="comments"> <hr> <h2 id="comments-header"> Comments </h2> <div class="comment" id="6d45d75e1bfd495a8cd688768f960c06"> <div class="comment-author">Ramon Pfeiffer</div> <div class="comment-content"> <p> Hi Mark, </p> <p> aren't you loading more responsibilities on the <code>ReservationsController</code>? Previously, it only had to delegate all the work to <code>MaîtreD</code> and return an appropriate result, now it additionally fetches reservations from the repository. You are also loading the handling of any errors the reservations repository might throw onto the controller, instead of handling them in the <code>MaîtreD</code> class. </p> <p> You are also hard wiring a dependency on <code>MaîtreD</code> into the <code>ReservationsController</code>; I thought one of the advantages of DI were to avoid newing up dependencies to concrete implementations outside of a centralized "builder class". </p> <p> Could you elaborate on these points? Thanks! </p> </div> <div class="comment-date">2019-02-11 10:39 UTC</div> </div> <div class="comment" id="0961c2d19e0f4990941ba597ffc0514f"> <div class="comment-author"><a href="/">Mark Seemann</a></div> <div class="comment-content"> <p> Ramon, thank you for writing. Am I loading more responsibilities on the Controller? Yes, I am. Too many? I don't think so. </p> <p> To be fair, however, this example is unrealistically simplified (in order to make it easily understandable). There isn't much going on, overall, so one has to imagine that more things are happening than is actually the case. For instance, at the beginning of the example, so little is going on in the Controller that I think it'd be fair to ask why it's even necessary to distinguish between a Controller and a <code>MaîtreD</code> class. </p> <p> Usually, I'd say that the responsibility of a Controller object is to facilitate the translation of what goes on at the boundary of the application and what happens in the domain model. Using the terminology of the <a href="/2016/03/18/functional-architecture-is-ports-and-adapters">ports and adapters</a> architecture, you could say that a Controller's responsibility is to serve as an <a href="https://en.wikipedia.org/wiki/Adapter_pattern">Adapter</a> between the technology-agnostic domain model and the technology-specific SDKs you'll need to bring into play to communicate with the 'real world'. Talking to databases fits that responsibility, I think. </p> <p> The <code>MaîtreD</code> class didn't handle any database errors before, so I don't agree that I've moved that responsibility. </p> <p> When it comes to using a <code>MaîtreD</code> object from inside the Controller, I don't agree that I've 'hard-wired' it. It's not a dependency in the Dependency Injection sense; it's an implementation detail. Notice that it's a <code>private</code> class field. </p> <p> Is it an 'advantage of DI' that you can <em>"avoid newing up dependencies to concrete implementations outside of a centralized "builder class"?"</em> How is that an advantage? Is that a goal? </p> <p> In future articles, I'll discuss this sort of 'dependency elimination' in more details. </p> </div> <div class="comment-date">2019-02-11 15:29 UTC</div> </div> <div class="comment" id="b1876a214ea54221935748c21e148d2a"> <div class="comment-author">Ramon Pfeiffer</div> <div class="comment-content"> <p> Mark, thanks for replying. </p> <p> I assumed that some exception handling would be happening in the <code>MaitreD</code> class that would then migrate to the <code>ReservationsController</code> and you left it out for the sake of simplicity. But granted, that can still happen inside the respository class. </p> <p> Let's imagine that for some reason, you want to write to the filesystem in addition to the database (eg. writing some reservation data like table number that can be printed and given to the customer). Following your reasoning, there would now be a reference to some <code>IReservationPrinter</code> in the Controller. It suddenly has to hold references to all data exchange classes that it was previously unaware of, only caring about the result <code>MaîtreD</code> was returning. </p> <p> Maybe I didn't express myself properly: I thought Dependency Injection is a technique to resolve all implementation types at a single composition root. Of course this only applies to dependencies in the sense of DI, so where do you draw the line between implementation detail and dependency? </p> <p> In any case I'm looking forward to reading more articles on this topic! </p> </div> <div class="comment-date">2019-02-11 18:55 UTC</div> </div> <div class="comment" id="0ca54917c833417c816bf086d6324af5"> <div class="comment-author"><a href="/">Mark Seemann</a></div> <div class="comment-content"> <p> Ramon, in general when it comes to exception handling, you either handle exceptions at the source (i.e. in the Repository) or at the boundary of the application (which is typically done by frameworks already). <a href="/2013/07/08/defensive-coding">I'm no fan of defensive coding</a>. <blockquote> "It suddenly has to hold references to all data exchange classes that it was previously unaware of" </blockquote> Yes, but now <code>MaîtreD</code> doesn't have to do that. Is there anything inherently associated with business logic that stipulates that it handles data access? </p> <p> The following line of argument may be increasingly difficult to relate to as time moves forward, and business becomes increasingly digital, but there once was a time when business logic was paper-based. In paper-based organisations, data would flow through a business in the shape of paper; typically as forms. Data would arrive at the desk of a clerk or domain expert who would add more data or annotations to a form, and put it in his or her out-box for later collection. </p> <p> My point is that I see nothing inherent in business logic to stipulate that business objects should be responsible for data retrieval or persistence. I recommend <a href="https://amzn.to/2OyI51M">Domain Modeling Made Functional</a> if you're interested in a comprehensive treatment of this way of looking at modelling business logic. <blockquote> "I thought Dependency Injection is a technique to resolve all implementation types at a single composition root." </blockquote> It is, and that still happens here. There are, however, fewer dependencies overall. I would argue that with the final design outlined here, the remaining dependency (<code>IReservationsRepository</code>) is also, architecturally, the only real dependency of the application. The initial <code>IMaîtreD</code> dependency is, in my opinion, an implementation detail. Exposing it as a dependency makes the code more brittle, and harder to refactor, but that's what I'm going to cover in future articles. </p> </div> <div class="comment-date">2019-02-12 9:24 UTC</div> </div> <div class="comment" id="2f8b9958df594883994859909d1bd5d3"> <div class="comment-author">Ramon Pfeiffer</div> <div class="comment-content"> <p> Mark, I have to admit that I'm still not convinced (without having read the book you mentioned): </p> <p> Expanding on your analogy, a clerk would maybe make a phone call or walk over to another desk if he needs more information regarding his current form (I know I do at my office). A maître d'hôtel would presumably open his book of reservations to check if he still has a table available and would write a new reservation in his book. </p> <p> The <code>MaîtreD</code> doesn't need to know if the data it needs comes from the file system or a database or a web service (that's the responsibility of the repository class), all it cares about is that it needs some data. Currently, some other part of the system decides what data <code>MaîtreD</code> has to work with. </p> <p> Again, I didn't have a look at the reading recommendation yet. Maybe I should. ;) </p> </div> <div class="comment-date">2019-02-12 10:50 UTC</div> </div> <div class="comment" id="82fd379429464775b97f52b48c0a88c1"> <div class="comment-author">Tyson Williams</div> <div class="comment-content"> <p> I definitely agree with Mark that the business logic (in the final version of <code>MaîtreD.TryAccept</code>) should be in a function that is pure and synchronous. However, I am also sympathetic to Ramon's argument. </p> <p> There are two UIs for the application that I am currently building at work. The primary interface is over HTTP and uses web controllers just like in Mark's example. The second interface is a CLI (that is only accessable to administrators with phsyical access to the server). Suppose my application was also an on-line restaurant reservation system and that a reservation could be made with both UIs. </p> <p> Looking back at the final implementation of <code>ReservationsController.Post</code>, the first three lines are independent of <code>ControllerBase</code> and would also need to be executed when accessing the system though the CLI. My understanding is that Ramon's primary suggestion is to move these three lines into <code>MaîtreD.TryAccept</code>. I am sympathetic to Ramon's argument in that I am in favor of extracting those three lines. However, I don't want them to be colocated with the final implimentatiion of <code>MaîtreD.TryAccept</code>. </p> <p> In my mind, the single responsibility of <code>ReservationsController.Post</code> is to translate the result of the reseravation request into the expected type of response. That would be just the fourth line in the final implementation of this method. In terms of naming, I like Ramon's suggestion that the first three lines of <code>ReservationsController.Post</code> be moved to <code>MaîtreD.TryAccept</code>. But then I also want to move the final implementation of <code>MaîtreD.TryAccept</code> to a method on a different type. As we all know, naming is an impossible problem, so I don't have a good name for this new third type. </p> <p> What do you think Ramon? Have I understood your concerns and suggested something that you could get behind? </p> <p> What about you Mark? You said that there was <blockquote> so little...going on in the Controller that I think it'd be fair to ask why it's even necessary to distinguish between a Controller and a <code>MaîtreD</code> class. </blockquote> Would two UIs be sufficient motivation in your eyes to justify distinguishing between a Controller and a <code>MaîtreD</code> class? </p> </div> <div class="comment-date">2019-02-12 17:00 UTC</div> </div> <div class="comment" id="0ecaa41899db43c6ae6eced05d7cf6e6"> <div class="comment-author"><a href="/">Mark Seemann</a></div> <div class="comment-content"> <p> Tyson, thank you for joining the discussion. By adding a particular problem (more than one user interface) to be addressed, you make the discussion more specific. I think this helps to clarify some issues. </p> <p> Ramon wrote: <blockquote> "I have to admit that I'm still not convinced" </blockquote> That's okay; you don't have to be. I rarely write articles with the explicit intent of telling people that they <em>must</em> do something, or that they should <em>never</em> do something else. While it does happen, this article isn't such an article. If it helps you address a problem, then take what you find useful. If it doesn't, then ignore it. </p> <p> With Tyson's help, though, we can now discuss something more concrete. I think some of those observations identify a tender spot in my line of argument. In the initial version of <code>ReservationsController</code>, the only responsibility of the <code>Post</code> method was to translate from and to HTTP. That's a distinct separation of responsibility, so clearly preferable. </p> <p> When I add the <code>Repository</code> dependency, I widen the scope of the <code>ReservationsController</code>'s responsibility, which now includes 'all IO'. This does blur the demarcation of responsibility, but often still works out well in practice, I find. Still, it depends on how much other stuff is going on related to IO. If you have too much IO going on, another separation of responsibilities is in order. </p> <p> I do find, however, that when implementing the same sort of software capability in different user interfaces, I need to specifically design for each user interface paradigm. A web-based user interface is quite different from a command-line interface, which is again different from a native application, or a voice-based interface, and so on. A web-based interface is, for example, stateless, whereas a native smart phone application would often be stateful. You can rarely reuse the 'user interface controller layer' for one type of application in a different type of application. </p> <p> Even a command-line interface could be stateful by <a href="/2017/07/17/a-pure-command-line-wizard">interactively asking a series of questions</a>. That's such a different user interface paradigm that an object designed for one type of interaction is rarely reusable in another context. </p> <p> What I do find is that fine-grained building blocks still compose. When <code>TryAccept</code> is a pure function, it's <em>always</em> composable. This means that my chance of being able to reuse it becomes much higher than if it's an object injected with various dependencies. <blockquote> "a clerk would maybe make a phone call or walk over to another desk if he needs more information regarding his current form" </blockquote> Indeed, but how do you model this in software? A program doesn't have the degree of ad-hoc flexibility that people have. It can't just arbitrarily decide to make a phone call if it doesn't have a 'phone' dependency. Even when using Dependency Injection, you'll have to add that dependency to a business object. You'll have to explicitly write code to give it that capability, and even so, an injected dependency doesn't magically imbue a business object with the capability to make 'ad-hoc phone calls'. A dependency comes with specific methods you can call in order to answer specific questions. </p> <p> Once you're adding code that enables an object to ask specific questions, you might as well just answer those questions up-front and pass the answer as method arguments. That's what this article's refactoring does. It knows that the <code>MaîtreD</code> object is going to ask about the existing reservations for the requested date, so it just passes that information as part of an 'execution context'. <blockquote> "A maître d'hôtel would presumably open his book of reservations to check if he still has a table available and would write a new reservation in his book" </blockquote> That's a brilliant observation! This just once again demonstrates what Evans wrote in <a href="http://amzn.to/WBCwx7">DDD</a>, that insight about the domain arrive piecemeal. A maître d'hôtel clearly doesn't depend on any <em>repository</em>, but rather on the book of reservations. You can add that as a dependency, or pass it as a method argument. I'd lean toward doing the latter, because I'd tend to view a book as a piece of data. </p> <p> Ultimately, if we are to take the idea of <em>inversion of control</em> seriously, we should, well, invert control. When we inject dependencies, we let the object with those dependencies control its interactions with them. Granted, those interactions are now polymorphic, but control isn't inverted. </p> <p> If you truly want to invert control, then load data, pass it to functions, and persist the return values. In that way, functions have no control of where data comes from, or what happens to it afterwards. This keeps a software design supple. </p> </div> <div class="comment-date">2019-02-13 7:26 UTC</div> </div> <div class="comment" id="c5208d5f4c534984891cdc6d5f5a9ca6"> <div class="comment-author">Marek Calus</div> <div class="comment-content"> <p> Hi Mark, Thanks for your post, I think it's very valuable. </p> <p> In the past, I had a situation when I was a junior software developer and just started working on a small, internal web application (ASP.NET MVC) to support HR processes in our company. At the time, I was discovering blogs like yours, or fsharpforfunandprofit.com and was especially fond of the sandwich architecture. I was preparing to refactor one of the controllers just like your example in this post (Controller retrieving necessary data from the repository, passing it to the pure business logic, then wrapping the results in a request). Unfortunately, My more experienced colleague said that it's a "fat controller antipattern" and that the controller can have only one line of code - redirecting the request to the proper business logic method. I wanted to explain to him that he is wrong, but couldn't find proper arguments, or examples. </p> <p> Now I have them. This post is great for this particular purpose. </p> </div> <div class="comment-date">2019-02-13 11:54 UTC</div> </div> <div class="comment" id="38791df654f84d438db15b3e79112e6d"> <div class="comment-author">Ramon Pfeiffer</div> <div class="comment-content"> <p> I guess it comes down to the amount of responsibilities the controller should have. </p> <p> Marek named the fat controller antipattern. I remember reading about some years ago and it stuck, that's why I usually model my controllers to delegate the request to a worker class, maybe map a return value to a transfer object and wrap it all in some <code>ActionResult</code>. I can relate to the argument that all I/O should happen at the boundaries of the system, though I'm not seeing it on the controller's responsibility list, all the more so when I/O exceeds a simple database call. </p> <blockquote> If you have too much IO going on, another separation of responsibilities is in order. </blockquote> <p> I think that is what I was aiming for. The third type that Tyson is looking a name for could then be some kind of thin Data Access Layer, serving as a façade to encapsulate all calls to I/O, that can be injected into the <code>MaîtreD</code> class. </p> <p> Isn't code flexibility usually modeled using conditionals? Assume we are a very important guest and our maître d'hôtel really wishes to make a reservation for us, but all tables are taken. He could decide to phone all currently known guests to ask for a confirmation, if some guest cannot make it, he could give the table to us. </p> <p> Using the initial version of <code>TryAccept</code>, it would lead to something like this: </p> <pre> public async Task&lt;int?&gt; TryAccept(Reservation reservation) { if(await CheckTableAvailability(reservation)) { reservation.IsAccepted = true; return await Repository.Create(reservation); } else { return null; } } private async Task&lt;bool&gt; CheckTableAvailability(Reservation reservation) { var reservations = await Repository.ReadReservations(reservation.Date); int reservedSeats = reservations.Sum(r => r.Quantity); if(Capacity < reservedSeats + reservation.Quantity) { foreach(var r in reservations) { if(!(await Telephone.AskConfirmation(r.Guest.PhoneNumber))) { //some guest cannot make it for his reservation return true; } } //all guests have confirmed their reservation - no table for us return false; } return true; } </pre> <p> That is assuming that <code>MaîtreD</code> has a dependency on both the Repository and a Telephone. Not the best code I've ever written, but it serves its purpose. If the dependency on <code>Reservation</code> is taken out of the <code>MaîtreD</code>, so could the dependency on <code>Telephone</code>. But then, you are deciding beforehand in the controller that <code>MaîtreD</code> <i>might</i> need to make a telephone call - that's business logic in the controller class and a weaker separation of concerns. </p> <blockquote> A maître d'hôtel clearly doesn't depend on any repository, but rather on the book of reservations. You can add that as a dependency, or pass it as a method argument. I'd lean toward doing the latter, because I'd tend to view a book as a piece of data. </blockquote> <p> And this is where I tend to disagree. The book of reservations in my eyes is owned and preciously guarded by the maître d'hôtel. Imagine some lowly garçon scribbling reservations in it. Unbelievable! Joking aside, the reservations in the book are pieces of data, no doubt about that - but I'd see the whole book as a resource owned by le maître and only him being able to request data from it. Of course, this depends on the model of the restaurant that I have in my mind, it might very well be different from yours - we didn't talk about a common model beforehand. </p> </div> <div class="comment-date">2019-02-13 19:54 UTC</div> </div> <div class="comment" id="451723a601f9487397c9aa7fa09381dc"> <div class="comment-author">Ramon Pfeiffer</div> <div class="comment-content"> <p> Apparently, I answered my own question when I moved the table availability check into its own private method. This way, a new dependency <code>TableAvailabilityChecker</code> can handle the availability check (complete with reservations book and phone calls), acting as a common data access layer. </p> <p> I have created a <a href="https://github.com/Thaoden/RestaurantReservation" target="_blank">repository</a>, where I tried to follow the steps outlined in this blog post with the new dependency. After all refactorings the controller looks like this: </p> <pre> public class ReservationsController : ControllerBase { private readonly MaitreD _maitreD; public ReservationsController(int capacity, IReservationsRepository repository, ITelephone telephone) { _maitreD = new MaitreD(capacity); Repository = repository; Telephone = telephone; } public IReservationsRepository Repository { get; } public ITelephone Telephone { get; } public async Task<IActionResult> Post(Reservation reservation) { Reservation[] currentReservations = await Repository.ReadReservations(reservation.Date); var confirmationCalls = currentReservations.Select(cr => Telephone.AskConfirmation(cr.Guest.PhoneNumber)); return _maitreD.CheckTableAvailability(currentReservations, reservation) .Match( some: r => new Maybe<Reservation>(r), none: _maitreD.AskConfirmation(await Task.WhenAll(confirmationCalls), reservation) ) .Match( some: r => Ok(Repository.Create(_maitreD.Accept(r))), none: new ContentResult { Content = "Table unavailable", StatusCode = StatusCodes.Status500InternalServerError } as ActionResult ); } } </pre> <p> During the refactorings, I was able to remove the <code>TableAvailabilityChecker</code> again; I'm quite happy that the maître d'hôtel is checking the table availability and asking for the confirmations with the resources that are given to him. I'm not so happy with the <code>Task.WhenAll()</code> part, but I don't know how to make this more readable and at the same time make the calls only if we need them. </p> <p> All in all, I now think a bit differently about the controller responsibilities: Being at the boundary of the system, it is arguably the best place to make calls to external systems. If and how the information gathered from the outside <i>is used</i> however is still up to the business objects. Thanks, Mark, for the insight! </p> </div> <div class="comment-date">2019-02-15 11:40 UTC</div> </div> <div class="comment" id="b66a6b327b8949b69db335722c9501e1"> <div class="comment-author">Max</div> <div class="comment-content"> <p> Thanks for writing this article. Doesn't testability suffer from turning the Maître d into an implementation detail of the ReservationsController? Now, we not only have to test for the controller's specific responsibilities but also for the behaviour that is implemented by the Maître d. Previously we could have provided an appropriate test double when instantiating the controller, knowing that the Maître d is tested and working. The resulting test classes would be more specific and focused. Is this a trade-off you made in favour of bringing the article's point across? </p> </div> <div class="comment-date">2019-02-17 14:00 UTC</div> </div> <div class="comment" id="28415cd446b34649a210bc03c4e084e9"> <div class="comment-author"><a href="/">Mark Seemann</a></div> <div class="comment-content"> <p> Max, thank you for writing. I don't think that testability suffers; on the contrary, I think that it improves. Once the <code>MaîtreD</code> class becomes deterministic, you no longer have to hide it behind a Test Double in order to be able to control its behaviour. You can control its behaviour simply by making sure that it receives the appropriate input arguments. </p> <p> The <a href="/2012/06/27/FacadeTest">Facade Tests</a> that cover <code>ReservationsController</code> in <a href="https://github.com/ploeh/asynchronous-injection">the repository</a> are, in my opinion, readable and maintainable. </p> <p> I've started <a href="/2019/02/18/from-interaction-based-to-state-based-testing">a new article series about this topic</a>, since I knew it'd come up. I hope that these articles will help illustrate my position. </p> </div> <div class="comment-date">2019-02-18 8:33 UTC</div> </div> </div> <hr> This blog is totally free, but if you like it, please consider <a href="https://blog.ploeh.dk/support">supporting it</a>. Mark Seemann https://blog.ploeh.dk/2019/02/11/asynchronous-injection How to get the value out of the monad https://blog.ploeh.dk/2019/02/04/how-to-get-the-value-out-of-the-monad/ Mon, 04 Feb 2019 07:45:00 UTC <div id="post"> <p> <em>How do I get the value out of my monad? You don't. You inject the desired behaviour into the monad.</em> </p> <p> A frequently asked question about monads can be paraphrased as: <em>How do I get the value out of my monad?</em> This seems to particularly come up when the monad in question is <a href="https://www.haskell.org">Haskell</a>'s <code>IO</code> monad, from which you <em>can't</em> extract the value. This is by design, but then beginners are often stumped on how to write the code they have in mind. </p> <p> You can encounter variations of the question, or at least the underlying conceptual misunderstanding, with other monads. This seems to be particularly prevalent when object-oriented or procedural programmers start working with <a href="/2018/03/26/the-maybe-functor">Maybe</a> or <a href="/2019/01/14/an-either-functor">Either</a>. People really want to extract 'the value' from those monads as well, despite the lack of guarantee that there will be a value. </p> <p> So how do you extract the value from a monad? </p> <p> The answer isn't <em>use a comonad</em>, although it could be, for a limited set of monads. Rather, the answer is <a href="https://en.wikipedia.org/wiki/Mu_(negative)">mu</a>. </p> <h3 id="8edf2d16396b46ad9b5a7d595c36b4a5"> Unit containers <a href="#8edf2d16396b46ad9b5a7d595c36b4a5" title="permalink">#</a> </h3> <p> Before I attempt to address how to work with monads, I think it's worthwhile to speculate on what misleads people into thinking that it makes sense to even contemplate extracting 'the value' from a monad. After all, you rarely encounter the question: <em>How do I get the value out of my collection?</em> </p> <p> Various collections form monads, but everyone intuitively understand that there isn't a single value in a collection. Collections could be empty, or contain many elements. Collections could easily be the most ordinary monad. Programmers deal with collections all the time. </p> <p> Yet, I think that most programmers don't realise that collections form monads. The reason for this could be that mainstream languages rarely makes this relationship explicit. Even <a href="https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/query-syntax-and-method-syntax-in-linq">C# query syntax</a>, which is nothing but monads in disguise, hides this fact. </p> <p> What happens, I think, is that when programmers first come across monads, they often encounter one of a few <em>unit containers</em>. </p> <p> What's a <em>unit container?</em> I admit that the word is one I made up, because I couldn't detect existing terminology on this topic. The idea, though, is that it's a <a href="/2018/03/22/functors">functor</a> guaranteed to contain exactly one value. Since <a href="https://bartoszmilewski.com/2014/01/14/functors-are-containers">functors are containers</a>, I call such types <em>unit containers</em>. Examples include <a href="/2018/09/03/the-identity-functor">Identity</a>, <a href="/2018/09/10/the-lazy-functor">Lazy</a>, and <a href="/2018/09/24/asynchronous-functors">asynchronous functors</a>. </p> <p> You can extract 'the value' from most unit containers (with <code>IO</code> being the notable exception from the rule). Trivially, you can get the item contained in an Identity container: </p> <p> <pre>&gt; <span style="color:#2b91af;">Identity</span>&lt;<span style="color:blue;">string</span>&gt;&nbsp;x&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Identity</span>&lt;<span style="color:blue;">string</span>&gt;(<span style="color:#a31515;">"bar"</span>); &gt; x.Item "bar"</pre> </p> <p> Likewise, you can extract the value from lazy and asynchronous values: </p> <p> <pre>&gt; <span style="color:#4ec9b0;">Lazy</span>&lt;<span style="color:#569cd6;">int</span>&gt;&nbsp;x&nbsp;<span style="color:#b4b4b4;">=</span>&nbsp;<span style="color:#569cd6;">new</span>&nbsp;<span style="color:#4ec9b0;">Lazy</span>&lt;<span style="color:#569cd6;">int</span>&gt;(()&nbsp;<span style="color:#b4b4b4;">=&gt;</span>&nbsp;<span style="color:#b5cea8;">42</span>); &gt; x.Value 42 &gt; <span style="color:#4ec9b0;">Task</span>&lt;<span style="color:#569cd6;">int</span>&gt;&nbsp;y&nbsp;<span style="color:#b4b4b4;">=</span>&nbsp;<span style="color:#4ec9b0;">Task</span><span style="color:#b4b4b4;">.</span>Run(()&nbsp;<span style="color:#b4b4b4;">=&gt;</span>&nbsp;<span style="color:#b5cea8;">1337</span>); &gt; <span style="color:#569cd6;">await</span>&nbsp;y 1337</pre> </p> <p> My theory, then, is that some programmers are introduced to the concept of monads via lazy or asynchronous computations, and that this could establish incorrect mental models. </p> <h3 id="393e8bcfa18244a988ff8ea56a1209b3"> Semi-containers <a href="#393e8bcfa18244a988ff8ea56a1209b3" title="permalink">#</a> </h3> <p> There's another category of monad that we could call <em>semi-containers</em> (again, I'm open to suggestions for a better name). These are data containers that contain either a single value, or no value. In this set of monads, we find <a href="https://stackoverflow.com/a/48490711/126014">Nullable&lt;T&gt;</a>, Maybe, and Either. </p> <p> Unfortunately, Maybe implementations often come with an API that enables you to ask a Maybe object if it's populated or empty, and a way to extract the value from the Maybe container. This misleads many programmers to write code like this: </p> <p> <pre><span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">int</span>&gt;&nbsp;id&nbsp;=&nbsp;<span style="color:green;">//&nbsp;...</span> <span style="color:blue;">if</span>&nbsp;(id.HasItem) &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Customer</span>(id.Item); <span style="color:blue;">else</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">throw</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">DontKnowWhatToDoException</span>();</pre> </p> <p> Granted, in many cases, people do something more reasonable than throwing a useless exception. In a specific context, it may be clear what to do with an empty Maybe object, but there are problems with this Tester-Doer approach: <ul> <li>It doesn't compose.</li> <li>There's no systematic technique to apply. You always need to handle empty objects in a context-specific way.</li> </ul> These issues interact in unpleasant ways. </p> <p> If you throw an exception when the object is empty, you'll likely have to deal with that exception further up in the call stack. </p> <p> If you return a magic value (like returning <code>-1</code> when a natural number is expected), you again force all callers to check for that magic number. </p> <p> If you set a flag that indicates that an object was empty, again, you put the burden on callers to check for the flag. </p> <p> This leads to <a href="/2013/07/08/defensive-coding">defensive coding</a>, which, at best, makes the code unreadable. </p> <h3 id="f2fd9c0c72fd45ea86908edb606740b6"> Behaviour Injection <a href="#f2fd9c0c72fd45ea86908edb606740b6" title="permalink">#</a> </h3> <p> Interestingly, programmers rarely take a Tester-Doer approach to working with collections. Instead, they rely on APIs for collections and arrays. </p> <p> In C#, <a href="https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq">LINQ</a> has been around since 2007, and most programmers love it. It's common knowledge that you can use the <code>Select</code> method to, for example, convert an array of numbers to an array of strings: </p> <p> <pre>&gt; <span style="color:blue;">new</span>[]&nbsp;{&nbsp;42,&nbsp;1337,&nbsp;2112,&nbsp;90125&nbsp;}.Select(i&nbsp;=&gt;&nbsp;i.ToString()) string[4] { "42", "1337", "2112", "90125" }</pre> </p> <p> You can do that with all functors, including Maybe: </p> <p> <pre><span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">int</span>&gt;&nbsp;id&nbsp;=&nbsp;<span style="color:green;">//&nbsp;...</span> <span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">Customer</span>&gt;&nbsp;c&nbsp;=&nbsp;id.Select(x&nbsp;=&gt;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Customer</span>(x));</pre> </p> <p> A <a href="/2018/03/26/the-maybe-functor">previous article</a> offers a slightly more compelling example: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;viewModel&nbsp;=&nbsp;repository.Read(id).Select(r&nbsp;=&gt;&nbsp;r.ToViewModel());</pre> </p> <p> Common to all the three above examples is that instead of trying to extract a value from the monad (which makes no sense in the array example), you inject the desired behaviour into the context of the data container. What that eventually brings about depends on the monad in question. </p> <p> In the array example, the behaviour being injected is that of turning a number into a string. Since this behaviour is injected into a collection, it's applied to every element in the source array. </p> <p> In the second example, the behaviour being injected is that of turning an integer into a <code>Customer</code> object. Since this behaviour is injected into a Maybe, it's only applied if the source object is populated. </p> <p> In the third example, the behaviour being injected is that of turning a <code>Reservation</code> domain object into a View Model. Again, this only happens if the original Maybe object is populated. </p> <h3 id="9bfd775fc56740198bec05809c6c1b06"> Composability <a href="#9bfd775fc56740198bec05809c6c1b06" title="permalink">#</a> </h3> <p> The marvellous quality of a monad is that it's composable. You could, for example, start by attempting to parse a string into a number: </p> <p> <pre><span style="color:blue;">string</span>&nbsp;candidate&nbsp;=&nbsp;<span style="color:green;">//&nbsp;Some&nbsp;string&nbsp;from&nbsp;application&nbsp;boundary</span> <span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">int</span>&gt;&nbsp;idm&nbsp;=&nbsp;TryParseInt(candidate);</pre> </p> <p> This code could be defined in a part of your code base that deals with user input. Instead of trying to get 'the value' out of <code>idm</code>, you can pass the entire object to other parts of the code. The next step, defined in a different method, in a different class, perhaps even in a different library, then queries a database to read a <code>Reservation</code> object corresponding to that ID - if the ID is there, that is: </p> <p> <pre><span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">Reservation</span>&gt;&nbsp;rm&nbsp;=&nbsp;idm.SelectMany(repository.Read);</pre> </p> <p> The <code>Read</code> method on the repository has this signature: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">Reservation</span>&gt;&nbsp;Read(<span style="color:blue;">int</span>&nbsp;id)</pre> </p> <p> The <code>Read</code> method returns a <code>Maybe&lt;Reservation&gt;</code> object because you could pass any <code>int</code> to the method, but there may not be a row in the database that corresponds to that number. Had you used <code>Select</code> on <code>idm</code>, the return type would have been <code>Maybe&lt;Maybe&lt;Reservation&gt;&gt;</code>. This is a typical example of a nested functor, so instead, you use <code>SelectMany</code>, which flattens the functor. You can do this because Maybe is a monad. </p> <p> The result at this stage is a <code>Maybe&lt;Reservation&gt;</code> object. If all goes according to plan, it's populated with a <code>Reservation</code> object from the database. Two things could go wrong at this stage, though: <ol> <li>The <code>candidate</code> string didn't represent a number.</li> <li>The database didn't contain a row for the parsed ID.</li> </ol> If any of these errors occur, <code>idm</code> is empty. </p> <p> You can now pass <code>rm</code> to another part of the code base, which then performs this step: </p> <p> <pre><span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">ReservationViewModel</span>&gt;&nbsp;vm&nbsp;=&nbsp;rm.Select(r&nbsp;=&gt;&nbsp;r.ToViewModel());</pre> </p> <p> Functors and monads are composable (i.e. 'chainable'). This is a fundamental trait of functors; they're (endo)morphisms, which, by definition, are composable. In order to leverage that composability, though, you must retain the monad. If you extract 'the value' from the monad, composability is lost. </p> <p> For that reason, you're not supposed to 'get the value out of the monad'. Instead, you inject the desired behaviour into the monad in question, so that it stays composable. In the above example, <code>repository.Read</code> and <code>r.ToViewModel()</code> are behaviors injected into the Maybe monad. </p> <h3 id="e3be91ccb5a04a99a67d57c39e49b446"> Summary <a href="#e3be91ccb5a04a99a67d57c39e49b446" title="permalink">#</a> </h3> <p> When we learn something new, there's always a phase where we struggle to understand a new concept. Sometimes, we may, inadvertently, erect a tentative, but misleading mental model of a concept. It seems to me that this happens to many people while they're grappling with the concept of functors and monads. </p> <p> One common mental wrong turn that many people seem to take is to try to 'get the value out of the monad'. This seems to be particularly common with <code>IO</code> in Haskell, where the issue is a <a href="https://stackoverflow.com/q/51614573/126014">frequently</a> <a href="https://stackoverflow.com/q/8567743/126014">asked</a> <a href="https://stackoverflow.com/q/7314789/126014">question</a>. </p> <p> I've also reviewed enough <a href="https://fsharp.org">F#</a> code to have noticed that people often take the imperative, Tester-Doer road to <code>'a option</code>. That's the reason this article uses a majority of its space on various Maybe examples. </p> <p> In a future article, I'll show a more complete and compelling example of behaviour injection. </p> </div> <div id="comments"> <hr> <h2 id="comments-header"> Comments </h2> <div class="comment" id="3375d8afbf574cefa3bd95072d2a936c"> <div class="comment-author">Sean Donohue</div> <div class="comment-content"> <p> Hi Mark, was very interested in your post as I do try and use Option Monads in my code, and I think I understand the point you are making about not thinking of an optional value as something that is composable. However, I recently had a couple of situations where I reluctantly had to check the value, would really appreciate any thoughts you may have? </p> <p> The first example was where I have a UI and the user may specify a Latitude and a Longitude. The user may not yet have specified both values, so each is held as an Option<double>. We then need to calculate the rhumb bearing to a fixed location, so I wrote: <pre> if(latitude.HasValue && longitude.HasValue) Bearing = CalculateRhumbBearing(latitude.Value, longitude.Value, fixedLatitude, fixedLongitude).ToOptionMonad(); else Bearing = OptionMonad<double>.None; </pre> </p> <p> Having read your article, I realise I could change this to a Select statement on latitude, but that lambda would still need to check longitude.HasValue. Should I combine the two options somehow before doing a single Select? </p> <p> </p> <p> The second example again relates to a UI where the user can enter values in a grid, or leave a row blank. I would like to calculate the mean, standard deviation and root mean square of the values, and normally all these functions would have the signature: double Mean(ICollection<double> values) </p> <p> If I keep this then I need a function like <pre> foreach(var item in values) { if(item.HasValue) { yield return item.Value; } } </pre> </p> <p> Or some equivalent Where/Select combination. Can you advise me please, how you recommend transforming an IEnumerable<OptionMonad<X>> to an enumerable<X>? Or should I write a signature overload double Mean(ICollection<OptionMonad<double>> possibleValues) and ditto for SD and RMS? </p> <p> Thanks, Sean </p> </div> <div class="comment-date">2018-02-05 11:30 UTC</div> </div> <div class="comment" id="f8d3e120bf9a46d09b479106812e7020"> <div class="comment-author"><a href="/">Mark Seemann</a></div> <div class="comment-content"> <p> Sean, thank you for writing. The first example you give is quite common, and is easily addressed with using the <a href="/2018/10/29/the-maybe-applicative-functor">applicative</a> or monadic capabilities of <em>Maybe</em>. Often, in a language like C#, it's easiest to use monadic <em>bind</em> (in C# called <code>SelectMany</code>): </p> <p> <pre>Bearing&nbsp;=&nbsp;latitude &nbsp;&nbsp;&nbsp;&nbsp;.SelectMany(lat&nbsp;=&gt;&nbsp;longitude &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Select(lon&nbsp;=&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CalculateRhumbBearing(lat,&nbsp;lon,&nbsp;fixedLatitude,&nbsp;fixedLongitude)));</pre> </p> <p> If you find code like that disagreeable, you can also write it with query syntax: </p> <p> <pre>Bearing&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">from</span>&nbsp;lat&nbsp;<span style="color:blue;">in</span>&nbsp;latitude &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">from</span>&nbsp;lon&nbsp;<span style="color:blue;">in</span>&nbsp;longitude &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">select</span>&nbsp;CalculateRhumbBearing(lat,&nbsp;lon,&nbsp;fixedLatitude,&nbsp;fixedLongitude);</pre> </p> <p> Here, <code>Bearing</code> is a <em>Maybe</em> value. As you can see, in neither of the above alternatives is it necessary to check and extract the values. <code>Bearing</code> will be populated when both <code>latitude</code> and <code>longitude</code> are populated, and empty otherwise. </p> <p> Regarding the other question, being able to filter out empty values from a collection is a standard operation in both F# and Haskell. In C#, you can write it like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IEnumerable</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;Choose&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">IEnumerable</span>&lt;<span style="color:#2b91af;">IMaybe</span>&lt;<span style="color:#2b91af;">T</span>&gt;&gt;&nbsp;source) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;source.SelectMany(m&nbsp;=&gt;&nbsp;m.Match(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">T</span>[0],&nbsp;x&nbsp;=&gt;&nbsp;<span style="color:blue;">new</span>[]&nbsp;{&nbsp;x&nbsp;})); }</pre> </p> <p> This example is based on the <a href="/2018/06/04/church-encoded-maybe">Church-encoded Maybe</a>, which is currently my favourite implementation. I decided to call the method <code>Choose</code>, as this is also the name it has in F#. In Haskell, this function is called <code>catMaybes</code>. </p> </div> <div class="comment-date">2019-02-05 16:25 UTC</div> </div> <div class="comment" id="cd846c7abe1040edaeaa8ab97f7190ff"> <div class="comment-author">Achim Stuy</div> <div class="comment-content"> <p> Hi Mark, did you ever think about publishing a Library containing all these types missing in .net Framework like <code>Either</code>? Or can you recommend an existing library? </p> </div> <div class="comment-date">2019-02-07 07:59 UTC</div> </div> <div class="comment" id="885dd7685e8142d7b5af72796ea8c770"> <div class="comment-author"><a href="/">Mark Seemann</a></div> <div class="comment-content"> <p> Achim, thank you for writing. The thought has crossed my mind, but my position on this question seems to be changing. </p> <p> Had you asked me one or two years ago, I'd have answered that I hadn't seriously considered doing that, and that I saw little reason to do so. There is, as far as I can tell, plenty of such libraries out there, although I can't recommend any in particular. This seems to be something that many people create as part of a learning exercise. It seems to be a rite of passage for many people, similarly to developing a Dependency Injection container, or an ORM. </p> <p> Besides, a reusable library would mean another dependency that your code would have to take on. </p> <p> These days, however, I'm beginning to reconsider my position. It seems that no such library is emerging as dominant, and some of the types involved (particularly Maybe) would really be useful. </p> <p> Ideally, these types ought be in the .NET Base Class Library, but perhaps a second-best alternative would be to put them in a commonly-used shared library. </p> </div> <div class="comment-date">2019-02-07 11:15 UTC</div> </div> <div class="comment" id="88e67e633795438f9b1e927a6ca1410c"> <div class="comment-author">Ralph Hendriks</div> <div class="comment-content"> <p> Hi Mark, thank you for the interesting article series. </p> <p> Can you maybe provide guidance of how asynchronous operations can become part of a chain of operations? How would the 'functor flattening' be combined with the built Task/Task<T> types? Extending your example, how would you go about if we would like to enrich the reservation retrieved from repository with that day's special, which happens to be async: <pre> Task<ReservationWithMenuSuggestion> EnrichWithSpecialOfTheDayAsync(Reservation reservation) </pre> </p> <p> I tried with your Church encoded Maybe implementation, but I got stuck with the Task<T> wrapping/unwrapping/awaiting. </div> <div class="comment-date">2019-02-07 15:06 UTC</div> </div> <div class="comment" id="3588d6472d4f4e76832925221aae374a"> <div class="comment-author"><a href="/">Mark Seemann</a></div> <div class="comment-content"> <p> Ralph, thank you for writing. Please see if my new article <a href="/2019/02/11/asynchronous-injection">Asynchronous Injection</a> answers your question. </p> </div> <div class="comment-date">2019-02-11 7:56 UTC</div> </div> </div> <hr> This blog is totally free, but if you like it, please consider <a href="https://blog.ploeh.dk/support">supporting it</a>. Mark Seemann https://blog.ploeh.dk/2019/02/04/how-to-get-the-value-out-of-the-monad Better abstractions revisited https://blog.ploeh.dk/2019/01/28/better-abstractions-revisited/ Mon, 28 Jan 2019 07:45:00 UTC <div id="post"> <p> <em>How do you design better abstractions? A retrospective look on an old article for object-oriented programmers.</em> </p> <p> About a decade ago, I had already been doing test-driven development (TDD) and used Dependency Injection for many years, but I'd started to notice some patterns about software design. I'd noticed that <a href="/2010/12/02/Interfacesarenotabstractions">interfaces aren't abstractions</a> and that <a href="/2010/12/22/TheTDDApostate">TDD isn't a design methodology</a>. Sometimes, I'd arrive at interfaces that turned out to be good abstractions, but at other times, the interfaces I created seemed to serve no other purpose than enabling unit testing. </p> <p> In 2010 I thought that I'd noticed some patterns for good abstractions, so I wrote an article called <a href="/2010/12/03/Towardsbetterabstractions">Towards better abstractions</a>. I still consider it a decent attempt at communicating my findings, but I don't think that I succeeded. My thinking on the subject was still too immature, and I lacked a proper vocabulary. </p> <p> While I had hoped that I would be able to elaborate on such observations, and perhaps turn them into heuristics, my efforts soon after petered out. I moved on to other things, and essentially gave up on this particular research programme. Years later, while trying to learn <a href="https://en.wikipedia.org/wiki/Category_theory">category theory</a>, I suddenly realised that mathematical disciplines like category theory and abstract algebra could supply the vocabulary. After some further work, I started publishing a substantial and long-running article series called <a href="/2017/10/04/from-design-patterns-to-category-theory">From design patterns to category theory</a>. It goes beyond my initial attempt, but it finally enabled me to crystallise those older observations. </p> <p> In this article, I'll revisit that old article, <em>Towards better abstractions</em>, and translate the vague terminology I used then, to the terminology presented in <em>From design patterns to category theory</em>. </p> <p> The thrust of the old article is that if you can create a <a href="http://en.wikipedia.org/wiki/Composite_pattern">Composite</a> or a <a href="http://en.wikipedia.org/wiki/Null_Object_pattern">Null Object</a> from an interface, then it's likely to be a good abstraction. I still consider that a useful rule of thumb. </p> <p> When can you create a Composite? <a href="/2018/03/12/composite-as-a-monoid">When the abstraction gives rise to a monoid</a>. When can you create a Null Object? <a href="/2018/04/23/null-object-as-identity">When the abstraction gives rise to a monoid</a>. </p> <p> <img src="/content/binary/better-abstractions-as-monoids.png" alt="The terms from the better abstractions article embedded in the set of monoids."> </p> <p> All the 'API shapes' I'd identified in <em>Towards better abstractions</em> form <a href="/2017/10/06/monoids">monoids</a>. </p> <h3 id="8ef17cb1e20547af9515c874d23a574d"> Commands <a href="#8ef17cb1e20547af9515c874d23a574d" title="permalink">#</a> </h3> <p> A <a href="https://en.wikipedia.org/wiki/Command_pattern">Command</a> seems to be universally identified by a method typically called <code>Execute</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Execute()</pre> </p> <p> From <a href="/2018/01/15/unit-isomorphisms">unit isomorphisms</a> we know that methods with the <code>void</code> return type are <a href="/2018/01/08/software-design-isomorphisms">isomorphic</a> to (impure) functions that return <em>unit</em>, and that <em>unit</em> forms a monoid. </p> <p> Furthermore, we know from <a href="/2017/11/06/function-monoids">function monoids</a> that methods that return a monoid themselves form monoids. Therefore, Commands form monoids. </p> <p> In early 2011 I'd already explicitly noticed that <a href="/2011/03/22/CommandsareComposable">Commands are composable</a>. Now I know the deeper reason for this: they're monoids. </p> <h3 id="42ac895ddb2a4fa8be678f4c74493cfc"> Closure of operations <a href="#42ac895ddb2a4fa8be678f4c74493cfc" title="permalink">#</a> </h3> <p> In <a href="http://amzn.to/WBCwx7">Domain-Driven Design</a>, Eric Evans discusses the benefits of designing APIs that exhibit <em>closure of operations</em>. This means that a method returns the same type as all its input arguments. The simplest example is the one that I show in the old article: </p> <p> <pre><span style="color:blue;">public&nbsp;static</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;DoIt(<span style="color:#2b91af;">T</span>&nbsp;x)</pre> </p> <p> That's just an <a href="/2017/11/13/endomorphism-monoid">endomorphism, which forms a monoid</a>. </p> <p> Another variation is a method that takes two arguments: </p> <p> <pre><span style="color:blue;">public&nbsp;static</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;DoIt(<span style="color:#2b91af;">T</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">T</span>&nbsp;y)</pre> </p> <p> This is a binary operation. While it's certainly a <a href="/2017/12/27/magmas">magma</a>, in itself it's not guaranteed to be a monoid. In fact, Evans' <a href="/2018/01/02/colour-mixing-magma">colour-mixing example is only a magma</a>, but not a monoid. You can, however, also view this as a special case of the <em>reduction of input</em> shape, below, where the 'extra' arguments just happen to have the same type as the return type. In that interpretation, such a method still forms a monoid, but it's not guaranteed to be meaningful. (Just like modulo 31 addition forms a monoid; it's hardly useful.) </p> <p> The same sort of argument goes for methods with closure of operations, but more input arguments, like: </p> <p> <pre><span style="color:blue;">public&nbsp;static</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;DoIt(<span style="color:#2b91af;">T</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">T</span>&nbsp;y,&nbsp;<span style="color:#2b91af;">T</span>&nbsp;z)</pre> </p> <p> This sort of method is, however, rare, unless you're working in a <a href="http://wiki.c2.com/?StringlyTyped">stringly typed</a> code base where methods look like this: </p> <p> <pre><span style="color:blue;">public&nbsp;static</span>&nbsp;<span style="color:blue">string</span>&nbsp;DoIt(<span style="color:blue">string</span>&nbsp;x,&nbsp;<span style="color:blue">string</span>&nbsp;y,&nbsp;<span style="color:blue">string</span>&nbsp;z)</pre> </p> <p> That's a different situation, though, because those strings should probably be <a href="/2015/01/19/from-primitive-obsession-to-domain-modelling">turned into domain types</a> that properly communicate their roles. Once you do that, you'll probably find that the method arguments have different types. </p> <p> In any case, regardless of cardinality, you can view all methods with closure of operations as special cases of the <em>reduction of input</em> shape below. </p> <h3 id="047886dcfa5a4a1398965138669e0ddc"> Reduction of input <a href="#047886dcfa5a4a1398965138669e0ddc" title="permalink">#</a> </h3> <p> This is the part of the original article where my struggles with vocabulary began in earnest. The situation is when you have a method that looks like this, perhaps as an interface method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">T1</span>&nbsp;DoIt(<span style="color:#2b91af;">T1</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">T2</span>&nbsp;y,&nbsp;<span style="color:#2b91af;">T3</span>&nbsp;z); }</pre> </p> <p> In order to stay true to the terminology of my original article, I've named this <em>reduction of input</em> generic example <code>IInputReducer</code>. The reason I originally called it <em>reduction of input</em> is that such a method takes a set of input types as arguments, but only returns a value of a type that's a subset of the set of input types. Thus, the method looks like it's reducing the range of input types to a single one of those types. </p> <p> <img src="/content/binary/reduction-of-input.png" alt="Diagram showing three generic types T1, T2, and T3 entering a funnel that only lets T1 pass through."> </p> <p> A realistic example could be a piece of HTTP middleware that defines an <em>action filter</em> as an interface that you can implement to intercept each HTTP request: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IActionFilter</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Task</span>&lt;<span style="color:#2b91af;">HttpResponseMessage</span>&gt;&nbsp;ExecuteActionFilterAsync( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">HttpActionContext</span>&nbsp;actionContext, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">CancellationToken</span>&nbsp;cancellationToken, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Task</span>&lt;<span style="color:#2b91af;">HttpResponseMessage</span>&gt;&nbsp;continuation); }</pre> </p> <p> This is a slightly modified version of <a href="https://docs.microsoft.com/en-us/previous-versions/aspnet/mt175073(v%3dvs.118)">an earlier version of the ASP.NET Web API</a>. Notice that in this example, it's not the first argument's type that doubles as the return type, but rather the third and last argument. The <em>reduction of input</em> 'shape' can take an arbitrary number of arguments, and any of the argument types can double as a return type, regardless of position. </p> <p> Returning to the generic <code>IInputReducer</code> example, you can easily make a Composite of it: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">CompositeInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;&nbsp;:&nbsp;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;[]&nbsp;reducers; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;CompositeInputReducer(<span style="color:blue;">params</span>&nbsp;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;[]&nbsp;reducers) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.reducers&nbsp;=&nbsp;reducers; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">T1</span>&nbsp;DoIt(<span style="color:#2b91af;">T1</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">T2</span>&nbsp;y,&nbsp;<span style="color:#2b91af;">T3</span>&nbsp;z) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;acc&nbsp;=&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;reducer&nbsp;<span style="color:blue;">in</span>&nbsp;reducers) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;acc&nbsp;=&nbsp;reducer.DoIt(acc,&nbsp;y,&nbsp;z); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;acc; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Notice that you call <code>DoIt</code> on all the composed <code>reducers</code>. The arguments that aren't part of the return type, <code>y</code> and <code>z</code>, are passed to each call to <code>DoIt</code> unmodified, whereas the <code>T1</code> value <code>x</code> is only used to initialise the accumulator <code>acc</code>. Each call to <code>DoIt</code> also returns a <code>T1</code> object, so the <code>acc</code> value is updated to that object, so that you can use it as an input for the next iteration. </p> <p> This is an imperative implementation, but as you'll see below, you can also implement the same behaviour in a functional manner. </p> <p> For the sake of argument, pretend that you reorder the method arguments so that the method looks like this: </p> <p> <pre><span style="color:#2b91af;">T1</span>&nbsp;DoIt(<span style="color:#2b91af;">T3</span>&nbsp;z,&nbsp;<span style="color:#2b91af;">T2</span>&nbsp;y,&nbsp;<span style="color:#2b91af;">T1</span>&nbsp;x);</pre> </p> <p> From <a href="/2018/02/05/uncurry-isomorphisms">Uncurry isomorphisms</a> you know that a method like that is isomorphic to a function with the type <code>'T3 -&gt; 'T2 -&gt; 'T1 -&gt; 'T1</code> (<a href="https://fsharp.org">F#</a> syntax). You can think of such a curried function as a function that returns a function that returns a function: <code>'T3 -&gt; ('T2 -&gt; ('T1 -&gt; 'T1))</code>. The rightmost function <code>'T1 -&gt; 'T1</code> is clearly an endomorphism, and you already know that an endomorphism gives rise to a monoid. Finally, <a href="/2017/11/06/function-monoids">Function monoids</a> informs us that a function that returns a monoid itself forms a monoid, so <code>'T2 -&gt; ('T1 -&gt; 'T1)</code> forms a monoid. This argument applies recursively, because if that's a monoid, then <code>'T3 -&gt; ('T2 -&gt; ('T1 -&gt; 'T1))</code> is also a monoid. </p> <p> What does that look like in C#? </p> <p> In the rest of this article, I'll revert the <code>DoIt</code> method signature to <code>T1 DoIt(T1 x, T2 y, T3 z);</code>. The monoid implementation looks much like the endomorphism code. Start with a binary operation: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;&nbsp;Append&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;&nbsp;r1, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;&nbsp;r2) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">AppendedReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;(r1,&nbsp;r2); } <span style="color:blue;">private</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">AppendedReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;&nbsp;:&nbsp;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;&nbsp;r1; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;&nbsp;r2; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;AppendedReducer( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;&nbsp;r1, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;&nbsp;r2) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.r1&nbsp;=&nbsp;r1; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.r2&nbsp;=&nbsp;r2; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">T1</span>&nbsp;DoIt(<span style="color:#2b91af;">T1</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">T2</span>&nbsp;y,&nbsp;<span style="color:#2b91af;">T3</span>&nbsp;z) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;r2.DoIt(r1.DoIt(x,&nbsp;y,&nbsp;z),&nbsp;y,&nbsp;z); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> This is similar to the endomorphism <code>Append</code> implementation. When you combine two <code>IInputReducer</code> objects, you receive an <code>AppendedReducer</code> that implements <code>DoIt</code> by first calling <code>DoIt</code> on the first object, and then using the return value from that method call as the input for the second <code>DoIt</code> method call. Notice that <code>y</code> and <code>z</code> are just 'context' variables used for both reducers. </p> <p> Just like the endomorphism, you can also implement the <em>identity</em> input reducer: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">IdentityInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;&nbsp;:&nbsp;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">T1</span>&nbsp;DoIt(<span style="color:#2b91af;">T1</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">T2</span>&nbsp;y,&nbsp;<span style="color:#2b91af;">T3</span>&nbsp;z) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> This simply returns <code>x</code> while ignoring <code>y</code> and <code>z</code>. The <code>Append</code> method is associative, and the <code>IdentityInputReducer</code> is both <em>left</em> and <em>right identity</em> for the operation, so this is a monoid. Since <a href="/2017/11/20/monoids-accumulate">monoids accumulate</a>, you can also implement an <code>Accumulate</code> extension method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;&nbsp;Accumulate&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;&gt;&nbsp;reducers) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;&nbsp;identity&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">IdentityInputReducer</span>&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>,&nbsp;<span style="color:#2b91af;">T3</span>&gt;(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;reducers.Aggregate(identity,&nbsp;(acc,&nbsp;reducer)&nbsp;=&gt;&nbsp;acc.Append(reducer)); }</pre> </p> <p> This implementation follows the overall implementation pattern for accumulating monoidal values: start with the identity and combine pairwise. While I usually show this in a more imperative form, I've here used a proper functional implementation for the method. </p> <p> The <code>IInputReducer</code> object returned from that <code>Accumulate</code> function has exactly the same behaviour as the <code>CompositeInputReducer</code>. </p> <p> The <em>reduction of input</em> shape forms another monoid, and is therefore composable. The Null Object is the <code>IdentityInputReducer&lt;T1, T2, T3&gt;</code> class. If you set <code>T1 = T2 = T3</code>, you have the <em>closure of operations</em> 'shapes' discussed above; they're just special cases, so form at least this type of monoid. </p> <h3 id="53d27a7c707943b5b2d502e6f7977526"> Composable return types <a href="#53d27a7c707943b5b2d502e6f7977526" title="permalink">#</a> </h3> <p> The original article finally discusses methods that in themselves don't look composable, but turn out to be so anyway, because their return types are composable. Without knowing it, I'd figured out that <a href="/2017/11/06/function-monoids">methods that return monoids are themselves monoids</a>. </p> <p> In 2010 I didn't have the vocabulary to put this into specific language, but that's all it says. </p> <h3 id="8b801b9446f34a2587d844b9eb67a6bd"> Summary <a href="#8b801b9446f34a2587d844b9eb67a6bd" title="permalink">#</a> </h3> <p> In 2010 I apparently discovered an ad-hoc, informally specified, vaguely glimpsed, half-understood description of half of abstract algebra. </p> <p> Riffs on <a href="https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule">Greenspun's tenth rule</a> aside, things clicked for me once I started to investigate what category theory was about, and why it seemed so closely linked to <a href="https://www.haskell.org">Haskell</a>. That's one of the reasons I started writing the <a href="/2017/10/04/from-design-patterns-to-category-theory">From design patterns to category theory</a> article series. </p> <p> The patterns I thought that I could see in 2010 all form monoids, but there are many other universal abstractions from mathematics that apply to programming as well. </p> </div><hr> This blog is totally free, but if you like it, please consider <a href="https://blog.ploeh.dk/support">supporting it</a>. Mark Seemann https://blog.ploeh.dk/2019/01/28/better-abstractions-revisited Some thoughts on anti-patterns https://blog.ploeh.dk/2019/01/21/some-thoughts-on-anti-patterns/ Mon, 21 Jan 2019 07:30:00 UTC <div id="post"> <p> <em>What's an anti-pattern? Are there rules to identify them, or is it just name-calling? Before I use the term, I try to apply some rules of thumb.</em> </p> <p> It takes time to write a book. Months, even years. It took me two years to write the first edition of <a href="http://amzn.to/12p90MG">Dependency Injection in .NET</a>. The <a href="https://amzn.to/2TE8tJx">second edition of Dependency Injection in .NET</a> is also the result of much work; not so much by me, but by my co-author <a href="http://www.cuttingedge.it/blogs/steven">Steven van Deursen</a>. </p> <p> When you write a book single-handedly, you can be as opinionated as you'd like. When you have a co-author, regardless of how much you think alike, there's bound to be some disagreements. Steven and I agreed about most of the changes we'd like to make to the second edition, but each of us had to yield or compromise a few times. </p> <p> An interesting experience has been that on more than one occasion where I've reluctantly had to yield to Steven, over the time, I've come to appreciate his position. Two minds think better than one. </p> <h3 id="6497bdfd47db433c92a6ec4fabfd4e92"> Ambient Context <a href="#6497bdfd47db433c92a6ec4fabfd4e92" title="permalink">#</a> </h3> <p> One of the changes that Steven wanted to make was that he wanted to change the status of the <em>Ambient Context</em> pattern to an anti-pattern. While I never use that pattern myself, I included it in the first edition in the spirit of the original <a href="http://amzn.to/XBYukB">Design Patterns</a> book. The <em>Gang of Four</em> made it clear that the patterns they'd described weren't invented, but rather discovered: <blockquote> <p> "We have included only designs that have been applied more than once in different systems." </p> <footer><cite>Gamma et al, <em>Design Patterns</em>, 1994, p. 2</cite></footer> </blockquote> The spirit, as I understand it, is to identify solutions that already exist, and catalogue them. When I wrote the first edition of my book, I tried to do that as well. </p> <p> I'd noticed what I eventually named the <em>Ambient Context</em> pattern several places in the .NET Base Class Library. Some of those APIs are still around today. <a href="https://docs.microsoft.com/dotnet/api/system.threading.thread.currentprincipal">Thread.CurrentPrincipal</a>, <a href="https://docs.microsoft.com/dotnet/api/system.globalization.cultureinfo.currentculture">CultureInfo.CurrentCulture</a>, <a href="https://en.wikipedia.org/wiki/Thread-local_storage">thread-local storage</a>, <a href="https://docs.microsoft.com/dotnet/api/system.web.httpcontext.current">HttpContext.Current</a>, and so on. </p> <p> None of these really have anything to do with Dependency Injection (DI), but people sometimes attempt to use them to solve problems similar to the problems that DI addresses. For that reason, and because the pattern was so prevalent, I included it in the book - as a pattern, not an anti-pattern. </p> <p> Steven wanted to make it an anti-pattern, and I conceded. I wasn't sure I was ready to explicitly call it out as an anti-pattern, but I agreed to the change. I'm becoming increasingly happy that Steven talked me into it. </p> <h3 id="08fbf0fd59154a57bbba936128f6c60e"> Pareto efficiency <a href="#08fbf0fd59154a57bbba936128f6c60e" title="permalink">#</a> </h3> <p> I've heard said of me that I'm one of those people who call everything I don't like an anti-pattern. I don't think that's true. </p> <p> I think people's perception of me is skewed because even today, the most visited page (my greatest hit, if you will) is an article called <a href="/2010/02/03/ServiceLocatorisanAnti-Pattern">Service Locator is an Anti-Pattern</a>. (It concerns me a bit that an article from 2010 seems to be my crowning achievement. I hope I haven't peaked yet, but the numbers tell a different tale.) </p> <p> While I've used the term <em>anti-pattern</em> in other connections, I prefer to be conservative with my use of the word. I tend to use it only when I feel confident that something is, indeed, an anti-pattern. </p> <p> What's an anti-pattern? <a href="https://amzn.to/2VHDX3m">AntiPatterns</a> defines it like this: <blockquote> <p> "An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences." </p> <footer><cite>Brown et al, <em>AntiPatterns</em>, 1998, p. 7</cite></footer> </blockquote> As definitions go, it's quite amphibolous. Is it the problem that generates negative consequences? Hardly. In the context, it's clear that it's the solution that causes problems. In any case, just because it's in a book doesn't necessarily make it right, but I find it a good start. </p> <p> I think that the phrase <em>decidedly negative consequences</em> is key. Most solutions come with <em>some</em> disadvantages, but in order for a 'solution' to be an anti-pattern, the disadvantages must clearly outweigh any advantages produced. </p> <p> I usually look at it another way. If I can solve the problem in a different way that generates at least as many advantages, but fewer disadvantages, then the first 'solution' might be an anti-pattern. This way of viewing the problem may stem from my background in economics. In that perspective, an anti-pattern simply isn't <a href="https://en.wikipedia.org/wiki/Pareto_efficiency">Pareto optimal</a>. </p> <h3 id="eb04af30ae5b40529fda1588525aee6d"> Falsifiability <a href="#eb04af30ae5b40529fda1588525aee6d" title="permalink">#</a> </h3> <p> Another rule of thumb I employ to determine whether a solution could be an anti-pattern is <a href="https://en.wikipedia.org/wiki/Karl_Popper">Popper</a>'s concept of <a href="https://en.wikipedia.org/wiki/Falsifiability">falsifiability</a>. As a continuation of the Pareto efficiency perspective, an anti-pattern is a 'solution' that you can improve without any (significant) trade-offs. </p> <p> That turns claims about anti-patterns into falsifiable statements, which I consider is the most intellectually honest way to go about claiming that things are bad. </p> <p> Take, for example, the claim that <em>Service Locator is an anti-pattern</em>. In light of Pareto efficiency, that's a falsifiable claim. All you have to do to prove me wrong is to present a situation where Service Locator solves a problem, and I can't come up with a better solution. </p> <p> I made the claim about Service Locator in 2010, and so far, no one has been able to present such a situation, even though several have tried. I'm fairly confident making that claim. </p> <p> This way of looking at the term anti-pattern, however, makes me wary of declaiming solutions anti-patterns just because I don't like them. Could there be a counter-argument, some niche scenario, where the pattern actually couldn't be improved without trade-offs? </p> <p> I didn't take it lightly when Steven suggested making Ambient Context an anti-pattern. </p> <h3 id="e027fe12038c4160a3be19bce065cd74"> Preliminary status <a href="#e027fe12038c4160a3be19bce065cd74" title="permalink">#</a> </h3> <p> I've had some time to think about Ambient Context since I had the (civil) discussion with Steven. The more I think about it, the more I think that he's right; that Ambient Context really <em>is</em> an anti-pattern. </p> <p> I never use that pattern myself, so it's clear to me that for all the situations that I typically encounter, there's always better solutions, with no significant trade-offs. </p> <p> The question is: could there be some niche scenario that I'm not aware of, where Ambient Context is a bona fide good solution? </p> <p> The more I think about this, the more I'm beginning to believe that there isn't. It remains to be seen, though. It remains to be falsified. </p> <h3 id="ed7478fa76324922a5543964e9c8c48e"> Summary <a href="#ed7478fa76324922a5543964e9c8c48e" title="permalink">#</a> </h3> <p> I'm so happy that Steven van Deursen agreed to co-author the second edition of <em>Dependency Injection in .NET</em> with me. The few areas where we've disagreed, I've ultimately come around to agree with him. He's truly taken a good book and made it better. </p> <p> One of the changes is that Ambient Context is now classified as an anti-pattern. Originally, I wasn't sure that this was the correct thing to do, but I've since changed my mind. I do think that Ambient Context belongs in the anti-patterns chapter. </p> <p> I could be wrong, though. I was before. </p> </div> <div id="comments"> <hr> <h2 id="comments-header"> Comments </h2> <div class="comment" id="4493b077ecd84d6d8217d4944e11471a"> <div class="comment-author"><a href="https://rebus.fm">Mogens Heller Grabe</a></div> <div class="comment-content"> <p> Thanks for great input for discussion :P </p> <p> Like with all other patterns and anti-patterns, I think there's a time and a place. </p> <p> Simply looking at it in a one-dimensional manner, i.e. asking "does there exist a solution to this problem with the same advantages but less downsides?" must be qualified with "IN THIS TIME AND PLACE", in my opinion. </p> <p> This way, the patterns/anti-patterns distinction does not make that much sense in a global perspective, because all patterns can be an anti-patterns in some situations, and vice versa. </p> <p> For example, I like what <em>Ambient Context</em> does in <a href="https://github.com/rebus-org/Rebus">Rebus</a>: It provides a mechanism that enables user code to transparently enlist its bus operations in a unit of work, without requiring user code to pass that unit of work to each operation. </p> <p> This is very handy, e.g. in OWIN-based applications, where the unit of work can be managed by an OWIN middleware that uses a <a href="https://github.com/rebus-org/Rebus/wiki/Transactions#i-am-not-in-a-transaction---i-want-to-either-publish-a-message-or-send-several-messages"><code>RebusTransactionScope</code></a>, this way enlisting all send/publish operations on the bus in that unit of work. </p> <p> Had it not been possible to automatically pick up an ongoing ambient Rebus transaction context, one would probably need to pollute the interfaces of one's application with an <code>ITransactionContext</code> argument, thus not handling the cross-cutting concern of managing the unit of work in a cross-cutting manner. </p> </div> <div class="comment-date">2019-01-21 12:37 UTC</div> </div> <div class="comment" id="6d2c0b22097341acadc41e37ce4f1dc8"> <div class="comment-author"><a href="/">Mark Seemann</a></div> <div class="comment-content"> <p> Mogens, thank you for writing. The reason I explicitly framed my treatment in a discourse related to <a href="https://en.wikipedia.org/wiki/Pareto_efficiency">Pareto efficiency</a> is exactly because this view on optima is multi-dimensional. When considering whether a 'solution coordinate' is Pareto-optimal or not, the question is exactly whether or not it's possible to improve at least one dimension without exacerbating any other dimension. If you can make one dimension better <em>without trade-offs</em>, then you can make a Pareto improvement. If you can only make one dimension better at the cost of one or more other dimensions, then you already have a Pareto-optimal solution. </p> <p> The theory of Pareto efficiency doesn't say anything about the number of dimensions. Usually, as in the linked Wikipedia article, the concept is illustrated in the plane, but conceptually, it applies to an arbitrary number of dimensions. </p> <p> In the context of anti-patterns, those dimensions include time and place, as you say. </p> <p> I consider something to be an anti-pattern if I can make a change that constitutes an improvement in at least one dimension, without trading off of any other dimensions. In other words, in this article, I'm very deliberately not looking at it in a one-dimensional manner. </p> <p> As I wrote, I'm still not sure that Ambient Context is an anti-pattern (although I increasingly believe it to be). How can we even test that hypothesis when we can't really quantify software design? </p> <p> On the other hand, if we leave the question about Ambient Context for a moment, I feel confident that Service Locator is an anti-pattern, even in what you call a global perspective. The reason I believe that is that I made that falsifiable claim in 2010, and here, almost nine years later, no-one has successfully produced a valid counter-example. </p> <p> I don't have the same long history with the claim about Ambient Context, so I could be wrong. Perhaps you are, right now, proving me wrong. I can't tell, though, because I don't (yet) know enough about Rebus to be able to tell whether what you describe is Pareto-optimal. </p> <p> The question isn't whether the current design is 'handy'. The question is whether it's possible to come up with a design that's 'globally' better; i.e. either has all the advantages of the current design, but fewer disadvantages; or has more advantages, and only the same disadvantages. </p> <p> I may be able to suggest such an improvement if provided with some code examples, but in the end we may never agree whether one design is better than another. After all, since we can't quantify software design, a subjective judgement will always remain. </p> </div> <div class="comment-date">2019-01-24 8:00 UTC</div> </div> </div> <hr> This blog is totally free, but if you like it, please consider <a href="https://blog.ploeh.dk/support">supporting it</a>. Mark Seemann https://blog.ploeh.dk/2019/01/21/some-thoughts-on-anti-patterns