263 lines
14 KiB
HTML
263 lines
14 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<title>Canonical factories for testing with factory_girl_api</title>
|
|
<meta name="description" content="Modern web applications are often built as _single-page apps_, which are great for keeping concerns separated, but problematic when tested. Logic needs to be duplicated in front- and back-end test suites, and if the two apps diverge, the tests won't catch...">
|
|
<meta name="author" content="Alexis King">
|
|
<meta name="keywords" content="ruby, rails, javascript, angular">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|
<link rel="icon" href="/favicon.ico">
|
|
<link rel="canonical" href="http://lexi-lambda.github.io/blog/2015/09/23/canonical-factories-for-testing-with-factory-girl-api/">
|
|
<link rel="next" href="/blog/2015/08/30/managing-application-configuration-with-envy/">
|
|
<link rel="prev" href="/blog/2015/11/06/functionally-updating-record-types-in-elm/">
|
|
<!-- CSS -->
|
|
<link rel="stylesheet" type="text/css" href="//fonts.googleapis.com/css?family=Merriweather+Sans:400,300,300italic,400italic,700,700italic,800,800italic|Merriweather:400,300,300italic,400italic,700,700italic,900,900italic|Source+Code+Pro:200,300,400,500,600,700,900">
|
|
<link rel="stylesheet" type="text/css" href="/css/application.min.css">
|
|
<link rel="stylesheet" type="text/css" href="/css/pygments.min.css">
|
|
<!-- Feeds -->
|
|
<link rel="alternate" type="application/atom+xml"
|
|
href="/feeds/all.atom.xml" title="Atom Feed">
|
|
<link rel="alternate" type="application/rss+xml"
|
|
href="/feeds/all.rss.xml" title="RSS Feed">
|
|
<!-- JS -->
|
|
<!-- <script src="/js/application.min.js"></script> -->
|
|
<script type="text/javascript">
|
|
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
|
|
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
|
|
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
|
|
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
|
|
|
|
ga('create', 'UA-65250372-1', 'auto');
|
|
ga('send', 'pageview');
|
|
</script>
|
|
</head>
|
|
<body>
|
|
<div id="page-content">
|
|
<!-- Navigation Bar -->
|
|
<header>
|
|
<nav role="navigation" class="navigation-bar">
|
|
<ul class="navigation-items left">
|
|
<li id="blog-title-header"><a href="/"><h1>Alexis King</h1></a></li>
|
|
</ul>
|
|
<ul class="navigation-items center"></ul>
|
|
<ul class="navigation-items right">
|
|
<li><a href="/">Home</a></li>
|
|
<li><a href="/about.html">About</a></li>
|
|
</ul>
|
|
</nav>
|
|
</header>
|
|
<section role="main">
|
|
<!-- Main column -->
|
|
<div class="content" class="col-md-12">
|
|
|
|
|
|
|
|
<article class="main">
|
|
<header>
|
|
<h1 class="title">Canonical factories for testing with factory_girl_api</h1>
|
|
<div class='date-and-tags'>
|
|
<time datetime="2015-09-23T16:30:12">
|
|
2015-09-23
|
|
</time>
|
|
<span style="margin: 0 3px">⦿</span>
|
|
<span class="tags"><a href="/tags/ruby.html">ruby</a>, <a href="/tags/rails.html">rails</a>, <a href="/tags/javascript.html">javascript</a>, <a href="/tags/angular.html">angular</a></span>
|
|
</div>
|
|
</header>
|
|
|
|
<p>Modern web applications are often built as <em>single-page apps</em>, which are great for keeping concerns separated, but problematic when tested. Logic needs to be duplicated in front- and back-end test suites, and if the two apps diverge, the tests won’t catch the failure. I haven’t found a very good solution to this problem aside from brittle, end-to-end integration tests.</p>
|
|
|
|
<p>To attempt to address a fraction of this problem, I built <a href="https://github.com/lexi-lambda/factory_girl_api">factory_girl_api</a>, a way to share context setup between both sides of the application.</p>
|
|
<!-- more-->
|
|
|
|
<h1 id="a-brief-overview-of-factorygirl">A brief overview of factory_girl</h1>
|
|
|
|
<p>In the land of Ruby and Rails, <a href="https://github.com/thoughtbot/factory_girl">factory_girl</a> is a convenient gem for managing factories for models. Out of the box, it integrates with Rails’ default ORM, ActiveRecord, and provides declarative syntax for describing what attributes factories should initialize. For example, a factory declaration used to create a widget might look like this:</p>
|
|
|
|
<div class="brush: ruby">
|
|
<table class="sourcetable">
|
|
<tbody>
|
|
<tr>
|
|
<td class="linenos">
|
|
<div class="linenodiv">
|
|
<pre> 1
|
|
2
|
|
3
|
|
4
|
|
5
|
|
6
|
|
7
|
|
8
|
|
9
|
|
10</pre></div></td>
|
|
<td class="code">
|
|
<div class="source">
|
|
<pre><span></span><span class="no">FactoryGirl</span><span class="o">.</span><span class="n">define</span> <span class="k">do</span>
|
|
<span class="n">factory</span> <span class="ss">:widget</span> <span class="k">do</span>
|
|
<span class="n">sequence</span><span class="p">(</span><span class="ss">:name</span><span class="p">)</span> <span class="p">{</span> <span class="o">|</span><span class="nb">id</span><span class="o">|</span> <span class="s1">'Widget #'</span> <span class="o">+</span> <span class="nb">id</span> <span class="p">}</span>
|
|
<span class="n">price</span> <span class="mi">10</span>
|
|
|
|
<span class="n">trait</span> <span class="ss">:expensive</span> <span class="k">do</span>
|
|
<span class="n">price</span> <span class="mi">1000</span>
|
|
<span class="k">end</span>
|
|
<span class="k">end</span>
|
|
<span class="k">end</span>
|
|
</pre></div>
|
|
</td></tr></tbody></table>
|
|
</div>
|
|
|
|
<p>This makes it easy to create new instances of <code>Widget</code> and use them for unit tests. For example, this would create and persist a widget with a unique name and a price of 10 units:</p>
|
|
|
|
<div class="brush: ruby">
|
|
<table class="sourcetable">
|
|
<tbody>
|
|
<tr>
|
|
<td class="linenos">
|
|
<div class="linenodiv">
|
|
<pre>1</pre></div></td>
|
|
<td class="code">
|
|
<div class="source">
|
|
<pre><span></span><span class="n">widget</span> <span class="o">=</span> <span class="no">FactoryGirl</span><span class="o">.</span><span class="n">create</span> <span class="ss">:widget</span>
|
|
</pre></div>
|
|
</td></tr></tbody></table>
|
|
</div>
|
|
|
|
<p>We can also create more expensive widgets by using the <code>:expensive</code> trait.</p>
|
|
|
|
<div class="brush: ruby">
|
|
<table class="sourcetable">
|
|
<tbody>
|
|
<tr>
|
|
<td class="linenos">
|
|
<div class="linenodiv">
|
|
<pre>1</pre></div></td>
|
|
<td class="code">
|
|
<div class="source">
|
|
<pre><span></span><span class="n">expensive_widget</span> <span class="o">=</span> <span class="no">FactoryGirl</span><span class="o">.</span><span class="n">create</span> <span class="ss">:widget</span><span class="p">,</span> <span class="ss">:expensive</span>
|
|
</pre></div>
|
|
</td></tr></tbody></table>
|
|
</div>
|
|
|
|
<p>Any number of traits can be specified at once. Additionally, it is possible to override individual attributes manually.</p>
|
|
|
|
<div class="brush: ruby">
|
|
<table class="sourcetable">
|
|
<tbody>
|
|
<tr>
|
|
<td class="linenos">
|
|
<div class="linenodiv">
|
|
<pre>1</pre></div></td>
|
|
<td class="code">
|
|
<div class="source">
|
|
<pre><span></span><span class="n">fancy_widget</span> <span class="o">=</span> <span class="no">FactoryGirl</span><span class="o">.</span><span class="n">create</span> <span class="ss">:widget</span><span class="p">,</span> <span class="ss">:expensive</span><span class="p">,</span> <span class="nb">name</span><span class="p">:</span> <span class="s1">'Fancy Widget'</span>
|
|
</pre></div>
|
|
</td></tr></tbody></table>
|
|
</div>
|
|
|
|
<p>It works well, and it keeps initialization boilerplate out of individual tests.</p>
|
|
|
|
<h1 id="testing-on-the-front-end">Testing on the front-end</h1>
|
|
|
|
<p>Trouble arises when we need to write tests for the JavaScript application that use the same models. Suddenly, we need to duplicate the same kind of logic in our front-end tests. We might start out by setting up object state manually:</p>
|
|
|
|
<div class="brush: js">
|
|
<table class="sourcetable">
|
|
<tbody>
|
|
<tr>
|
|
<td class="linenos">
|
|
<div class="linenodiv">
|
|
<pre>1
|
|
2
|
|
3
|
|
4</pre></div></td>
|
|
<td class="code">
|
|
<div class="source">
|
|
<pre><span></span><span class="kd">var</span> <span class="nx">fancyWidget</span> <span class="o">=</span> <span class="k">new</span> <span class="nx">Widget</span><span class="p">({</span>
|
|
<span class="nx">name</span><span class="o">:</span> <span class="s1">'Fancy Widget'</span><span class="p">,</span>
|
|
<span class="nx">price</span><span class="o">:</span> <span class="mi">1000</span>
|
|
<span class="p">});</span>
|
|
</pre></div>
|
|
</td></tr></tbody></table>
|
|
</div>
|
|
|
|
<p>Things can quickly get out of hand when models grow complex. Even if we use a factory library in JavaScript, it’s possible for our front-end factories to diverge from their back-end counterparts. This means our integration tests will fail, but our unit tests will still blindly pass. Having to duplicate all that logic in two places is dangerous. It would be nice to have a <em>single, canonical source</em> for all of our factories.</p>
|
|
|
|
<h2 id="reusing-server-side-factories-with-factorygirlapi">Reusing server-side factories with factory_girl_api</h2>
|
|
|
|
<p>To help alleviate this problem, I created the <a href="https://github.com/lexi-lambda/factory_girl_api">factory_girl_api</a> gem for Rails and the <a href="https://github.com/lexi-lambda/angular-factory-girl-api">angular-factory-girl-api</a> Bower package for Angular. These packages cooperate with each other to allow server-side factories to be used in JavaScript tests.</p>
|
|
|
|
<p>The Angular module provides a service with syntax comparable to factory_girl itself. Both traits and custom attributes are supported:</p>
|
|
|
|
<div class="brush: js">
|
|
<table class="sourcetable">
|
|
<tbody>
|
|
<tr>
|
|
<td class="linenos">
|
|
<div class="linenodiv">
|
|
<pre>1</pre></div></td>
|
|
<td class="code">
|
|
<div class="source">
|
|
<pre><span></span><span class="nx">FactoryGirl</span><span class="p">.</span><span class="nx">create</span><span class="p">(</span><span class="s1">'widget'</span><span class="p">,</span> <span class="s1">'expensive'</span><span class="p">,</span> <span class="p">{</span> <span class="nx">name</span><span class="o">:</span> <span class="s1">'Fancy Widget'</span> <span class="p">});</span>
|
|
</pre></div>
|
|
</td></tr></tbody></table>
|
|
</div>
|
|
|
|
<p>In this case, however, a round-trip API call must be made to the server in order to call the factory and return the result. Because of this, the Angular version of FactoryGirl returns a promise that is resolved with the serialized version of the model, which can then be used as sample data in unit tests.</p>
|
|
|
|
<h2 id="the-problems-with-relying-on-the-server-for-data">The problems with relying on the server for data</h2>
|
|
|
|
<p>In my preliminary use of this tool, it works. In many ways, it’s much nicer than duplicating logic in both places. However, I’m not <em>completely</em> convinced it’s the right solution yet.</p>
|
|
|
|
<p>First of all, it couples the front-end to the back-end, even during unit testing, which is disappointing. It means that a server needs to be running (in test mode) in order for the tests to run at all. For the kinds of projects I work on, this isn’t really a bad thing, and the benefits of the reduced duplication far outweigh the downsides.</p>
|
|
|
|
<p>My real concern is that this solves a very small facet of the general problem with fragile front-end test suites. Single-page applications usually depend wholly on their integration with back-end APIs. If those APIs change, the tests will continue to happily pass as long as the API is simply mocked, which seems to be the usual solution in the front-end universe. This is, frankly, unacceptable in real application development.</p>
|
|
|
|
<h2 id="potential-improvements-and-other-paths-to-success">Potential improvements and other paths to success</h2>
|
|
|
|
<p>I am ultimately unsatisfied with this approach, but writing brittle end-to-end integration tests is not the solution. This <em>kind</em> of thing may be a step in the right direction: writing tests that aren’t really pure unit tests, but also aren’t fragile full-stack integration tests. This is a middle-ground that seems infrequently traveled, perhaps due to a lack of tooling (or perhaps because it just doesn’t work). I don’t know.</p>
|
|
|
|
<p>Either way, I’m interested in where this is headed, and I’ll be curious to see if I run into any roadblocks using the workflow I’ve created. If anyone else is interested in playing with these two libraries, the READMEs are much more comprehensive than what I’ve covered here. Take a look, and give them a spin!</p>
|
|
|
|
<ul>
|
|
<li><a href="https://github.com/lexi-lambda/factory_girl_api">factory_girl_api</a></li>
|
|
<li><a href="https://github.com/lexi-lambda/angular-factory-girl-api">angular-factory-girl-api</a></li></ul>
|
|
<footer>
|
|
<script type="text/javascript">
|
|
var disqus_shortname = 'lexi-lambda';
|
|
(function() {
|
|
var dsq = document.createElement('script');
|
|
dsq.type = 'text/javascript';
|
|
dsq.async = true;
|
|
dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js';
|
|
(document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
|
|
})();
|
|
</script>
|
|
<div id="disqus_thread"></div>
|
|
<ul class="pager">
|
|
<li class="previous">
|
|
<a href="/blog/2015/11/06/functionally-updating-record-types-in-elm/">← <em>Functionally updating record types in Elm</em></a>
|
|
</li>
|
|
<li class="next">
|
|
<a href="/blog/2015/08/30/managing-application-configuration-with-envy/"><em>Managing application configuration with Envy</em> →</a>
|
|
</li>
|
|
</ul>
|
|
</footer>
|
|
</article>
|
|
</div>
|
|
</section>
|
|
<footer>
|
|
<div class="content">
|
|
<h2 id="copyright-notice">© 2016, Alexis King</h2>
|
|
<h3>
|
|
Built with <a href="https://github.com/greghendershott/frog">Frog</a>, the
|
|
<strong>fr</strong>ozen bl<strong>og</strong> tool.
|
|
</h3>
|
|
<h3>
|
|
Feeds are available via <a href="/feeds/all.atom.xml">Atom</a>
|
|
or <a href="/feeds/all.rss.xml">RSS</a>.
|
|
</h3>
|
|
</div>
|
|
</footer>
|
|
</div>
|
|
</body>
|
|
</html> |