---
layout: post
title: "From interaction-based to state-based testing"
description: "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."
date: 2019-02-18 8:19 UTC
tags: [Unit Testing, Article Series]
---
{% include JB/setup %}

<div id="post">
	<p>
		<em>{{ page.description }}</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="{{ site.production_url }}/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="{{ site.production_url }}/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><a href="/2019/04/01/an-example-of-state-based-testing-in-c">An example of state-based testing in C#</a></li>
			<li><a href="/2019/04/08/a-pure-test-spy">A pure Test Spy</a></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>