Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Add spec/support blog

  • Loading branch information...
commit 52325fc9e7f9c153872c83c93f245a9b0a665277 1 parent c982a1b
@radar authored
View
63 _posts/2013-02-02-about-spec-support.markdown
@@ -0,0 +1,63 @@
+---
+wordpress_id: RB-340
+layout: post
+title: About spec/support
+---
+
+I'm going to expand on a tweet I wrote this morning:
+
+<blockquote class="twitter-tweet"><p>Thinking more and more that spec/support is an anti-pattern. I don’t want everything required for every test.</p>&mdash; Ryan Bigg (@ryanbigg) <a href="https://twitter.com/ryanbigg/status/297497422396026881">February 2, 2013</a></blockquote><script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
+
+I came to this thought when I was working on sharing testing support code
+between an engine and an application, for an example in Chapter 4 of
+[Multitenancy with Rails](https://leanpub.com/multi-tenancy-rails). What I had
+originally was a file in `spec/support` called `SubdomainHelpers`, defined like
+this:
+
+ module SubdomainHelpers
+ def within_account_subdomain(&block)
+ context "within a subdomain" do
+ let(:subdomain_url) { "http://#{account.subdomain}.example.com" }
+ before { Capybara.default_host = subdomain_url }
+ after { Capybara.default_host = "http://example.com" }
+ yield
+ end
+ end
+ end
+
+This module is then used to extend the RSpec `describe` blocks, like this
+
+ describe "User sign in" do
+ extend SubdomainHelpers
+ ...
+ end
+
+And then we can call `within_account_subdomain` whenever we need it.
+
+---
+
+My problem with this is that this file is required *all the damn time*, even in
+tests which don't use Capybara. The culprit is this default line in
+`spec/spec_helper.rb`
+
+ Dir[File.dirname(__FILE__) + "/support/**/*.rb"].each {|f| require f }
+
+This line is used for requiring all the files in `spec/support` so that you
+don't have to. Seems like a good idea, but isn't once you have a ton of things
+in `spec/support`.
+
+Making it easy to require the file defining `SubdomainHelpers` in both the
+engine and the application involves moving the helper in to the `lib` directory
+of the engine, and then requiring that file in the appropriate places:
+
+ require 'subscribem/testing_support/subdomain_helpers'
+
+Even if we *weren't* using an engine and an application and just had the
+application, I would much rather just be requiring just the files I need for a
+test, like this:
+
+ require 'support/subdomain_helpers'
+
+Than having the full range of `spec/support` files loaded all at once on the
+off chance a spec might need it. I wouldn't expect this to *dramatically* increase a spec suite's
+run time, but it's got to be helping somewhat.
View
80 _site/2013/02/about-spec-support/index.html
@@ -0,0 +1,80 @@
+<!DOCTYPE HTML>
+<html>
+ <head>
+ <title>Blog of Ryan Bigg - About spec/support</title>
+ <link href="http://feeds.feedburner.com/ryanbigg" rel="alternate" title="The Life of a Radar" type="application/atom+xml" />
+ <link rel='stylesheet' href='/css/style.css' media='screen'>
+ <link rel='stylesheet' href='/css/mobile.css'>
+ <body>
+ <h1 align='center'><a href='http://ryanbigg.com'>The Life of a Radar</a></h1>
+ <div id='page'>
+ <article>
+ <a href="/2013/02/about-spec-support"><header>About spec/support</header></a>
+ <small>02 Feb 2013</small><br>
+ <p>I&#8217;m going to expand on a tweet I wrote this morning:</p>
+<blockquote class='twitter-tweet'><p>Thinking more and more that spec/support is an anti-pattern. I don’t want everything required for every test.</p>&mdash; Ryan Bigg (@ryanbigg) <a href='https://twitter.com/ryanbigg/status/297497422396026881'>February 2, 2013</a></blockquote>
+<p>I came to this thought when I was working on sharing testing support code between an engine and an application, for an example in Chapter 4 of <a href='https://leanpub.com/multi-tenancy-rails'>Multitenancy with Rails</a>. What I had originally was a file in <code>spec/support</code> called <code>SubdomainHelpers</code>, defined like this:</p>
+
+<pre><code>module SubdomainHelpers
+ def within_account_subdomain(&amp;block)
+ context &quot;within a subdomain&quot; do
+ let(:subdomain_url) { &quot;http://#{account.subdomain}.example.com&quot; }
+ before { Capybara.default_host = subdomain_url }
+ after { Capybara.default_host = &quot;http://example.com&quot; }
+ yield
+ end
+ end
+end</code></pre>
+
+<p>This module is then used to extend the RSpec <code>describe</code> blocks, like this</p>
+
+<pre><code>describe &quot;User sign in&quot; do
+ extend SubdomainHelpers
+ ...
+end</code></pre>
+
+<p>And then we can call <code>within_account_subdomain</code> whenever we need it.</p>
+<hr />
+<p>My problem with this is that this file is required <em>all the damn time</em>, even in tests which don&#8217;t use Capybara. The culprit is this default line in <code>spec/spec_helper.rb</code></p>
+
+<pre><code>Dir[File.dirname(__FILE__) + &quot;/support/**/*.rb&quot;].each {|f| require f }</code></pre>
+
+<p>This line is used for requiring all the files in <code>spec/support</code> so that you don&#8217;t have to. Seems like a good idea, but isn&#8217;t once you have a ton of things in <code>spec/support</code>.</p>
+
+<p>Making it easy to require the file defining <code>SubdomainHelpers</code> in both the engine and the application involves moving the helper in to the <code>lib</code> directory of the engine, and then requiring that file in the appropriate places:</p>
+
+<pre><code>require &#39;subscribem/testing_support/subdomain_helpers&#39;</code></pre>
+
+<p>Even if we <em>weren&#8217;t</em> using an engine and an application and just had the application, I would much rather just be requiring just the files I need for a test, like this:</p>
+
+<pre><code>require &#39;support/subdomain_helpers&#39;</code></pre>
+
+<p>Than having the full range of <code>spec/support</code> files loaded all at once on the off chance a spec might need it. I wouldn&#8217;t expect this to <em>dramatically</em> increase a spec suite&#8217;s run time, but it&#8217;s got to be helping somewhat.</p>
+ </article>
+ </div>
+ <div id='disqus_thread'></div>
+ <script type="text/javascript">
+ var disqus_shortname = 'ryanbigg'; // required: replace example with your forum shortname
+
+ var disqus_identifier = 'RB-340 http://ryanbigg.com/?p=RB-340'
+ var disqus_url = 'http://ryanbigg.com/2013/02/about-spec-support';
+ </script>
+ <script src='http://ryanbigg.disqus.com/embed.js'></script>
+
+ <noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
+ <a href="http://disqus.com" class="dsq-brlink">blog comments powered by <span class="logo-disqus">Disqus</span></a>
+ <script type="text/javascript">
+ var _gauges = _gauges || [];
+ (function() {
+ var t = document.createElement('script');
+ t.type = 'text/javascript';
+ t.async = true;
+ t.id = 'gauges-tracker';
+ t.setAttribute('data-site-id', '4e30f771f5a1f547c8000001');
+ t.src = '//secure.gaug.es/track.js';
+ var s = document.getElementsByTagName('script')[0];
+ s.parentNode.insertBefore(t, s);
+ })();
+ </script>
+ </body>
+</html>
View
64 _site/atom.xml
@@ -4,7 +4,7 @@
<title>The Life of a Radar</title>
<link href="http://ryanbigg.com/atom.xml" rel="self"/>
<link href="http://ryanbigg.com"/>
- <updated>2013-01-22T06:26:34+11:00</updated>
+ <updated>2013-02-02T11:41:52+11:00</updated>
<id>http://ryanbigg.com/</id>
<author>
<name>Ryan Bigg</name>
@@ -13,6 +13,52 @@
<entry>
+ <title>About spec/support</title>
+ <link href="http://ryanbigg.com/2013/02/about-spec-support"/>
+ <updated>2013-02-02T00:00:00+11:00</updated>
+ <id>http://ryanbigg.com/2013/02/about-spec-support</id>
+ <content type="html"><![CDATA[<p>I&#8217;m going to expand on a tweet I wrote this morning:</p>
+<blockquote class='twitter-tweet'><p>Thinking more and more that spec/support is an anti-pattern. I don’t want everything required for every test.</p>&mdash; Ryan Bigg (@ryanbigg) <a href='https://twitter.com/ryanbigg/status/297497422396026881'>February 2, 2013</a></blockquote>
+<p>I came to this thought when I was working on sharing testing support code between an engine and an application, for an example in Chapter 4 of <a href='https://leanpub.com/multi-tenancy-rails'>Multitenancy with Rails</a>. What I had originally was a file in <code>spec/support</code> called <code>SubdomainHelpers</code>, defined like this:</p>
+
+<pre><code>module SubdomainHelpers
+ def within_account_subdomain(&amp;block)
+ context &quot;within a subdomain&quot; do
+ let(:subdomain_url) { &quot;http://#{account.subdomain}.example.com&quot; }
+ before { Capybara.default_host = subdomain_url }
+ after { Capybara.default_host = &quot;http://example.com&quot; }
+ yield
+ end
+ end
+end</code></pre>
+
+<p>This module is then used to extend the RSpec <code>describe</code> blocks, like this</p>
+
+<pre><code>describe &quot;User sign in&quot; do
+ extend SubdomainHelpers
+ ...
+end</code></pre>
+
+<p>And then we can call <code>within_account_subdomain</code> whenever we need it.</p>
+<hr />
+<p>My problem with this is that this file is required <em>all the damn time</em>, even in tests which don&#8217;t use Capybara. The culprit is this default line in <code>spec/spec_helper.rb</code></p>
+
+<pre><code>Dir[File.dirname(__FILE__) + &quot;/support/**/*.rb&quot;].each {|f| require f }</code></pre>
+
+<p>This line is used for requiring all the files in <code>spec/support</code> so that you don&#8217;t have to. Seems like a good idea, but isn&#8217;t once you have a ton of things in <code>spec/support</code>.</p>
+
+<p>Making it easy to require the file defining <code>SubdomainHelpers</code> in both the engine and the application involves moving the helper in to the <code>lib</code> directory of the engine, and then requiring that file in the appropriate places:</p>
+
+<pre><code>require &#39;subscribem/testing_support/subdomain_helpers&#39;</code></pre>
+
+<p>Even if we <em>weren&#8217;t</em> using an engine and an application and just had the application, I would much rather just be requiring just the files I need for a test, like this:</p>
+
+<pre><code>require &#39;support/subdomain_helpers&#39;</code></pre>
+
+<p>Than having the full range of <code>spec/support</code> files loaded all at once on the off chance a spec might need it. I wouldn&#8217;t expect this to <em>dramatically</em> increase a spec suite&#8217;s run time, but it&#8217;s got to be helping somewhat.</p>]]></content>
+ </entry>
+
+ <entry>
<title>Multitenancy with Rails</title>
<link href="http://ryanbigg.com/2013/01/multitenancy-with-rails"/>
<updated>2013-01-21T00:00:00+11:00</updated>
@@ -1136,21 +1182,5 @@ Errata</a>. Has yours been updated? No? Neither have the three sitting on my ben
<p>Promise.</p>]]></content>
</entry>
- <entry>
- <title>Screencast: wrong argument type</title>
- <link href="http://ryanbigg.com/2011/11/screencast-wrong-argument-type"/>
- <updated>2011-11-23T00:00:00+11:00</updated>
- <id>http://ryanbigg.com/2011/11/screencast-wrong-argument-type</id>
- <content type="html"><![CDATA[<p>I am really surprised at how well-received my <a href='http://ryanbigg.com/2011/10/screencast-pilot/'>Conway's
-Game of Life</a> screencast was. Seems that everyone who watched it liked it, which is always a nice thing :)</p>
-
-<p>This week&#8217;s screencast is a slightly more advanced topic: debugging a <code>wrong argument type Module (expected
-class)</code> error which was happening inside of the <code>spree_paypal_express</code> Spree extension.</p>
-
-<p>It&#8217;s 28 minutes of debugging goodness and <a href='https://s3.amazonaws.com/ryanbigg_screencasts/002-wrong-argument-type.mov'>you can view it here</a>.</p>
-<hr />
-<p>The next screencasts I will do are examples of how to do nested attributes within Rails, covering <code>belongs_to</code>, <code>has_many</code> and <code>has_many :through</code> associations, along with demystifying how nested attributes works within Rails.</p>]]></content>
- </entry>
-
</feed>
View
2  _site/blogography.html
@@ -29,6 +29,8 @@ <h1 align='center'>The Life of a Radar</h1>
<p>The formatting for earlier posts may be a little skewiff. If you find something like that, <a href='http://github.com/radar/ryanbigg.com'>patches are very welcome</a>.</p>
<ul>
+ <li><a href="/2013/02/about-spec-support">About spec/support</a><abbr>02 Feb 2013</abbr></li>
+
<li><a href="/2013/01/multitenancy-with-rails">Multitenancy with Rails</a><abbr>21 Jan 2013</abbr></li>
<li><a href="/2013/01/a-story-about-scaffolding">A story about scaffolding</a><abbr>07 Jan 2013</abbr></li>
View
48 _site/index.html
@@ -30,25 +30,47 @@ <h1 align='center'>The Life of a Radar</h1>
http://litanyagainstfear.com -->
<div id='page'>
<article>
- <a href="/2013/01/multitenancy-with-rails"><header>Multitenancy with Rails</header></a>
- <small>21 Jan 2013</small><br>
- <p>Well before I had even <a href='http://ryanbigg.com/2012/11/no-more-writing-for-manning/'>split from Manning</a>, I had been working on a new book called <a href='https://leanpub.com/multi-tenancy-rails'>&#8220;Multitenancy with Rails&#8221;</a>, which you can buy right now.</p>
+ <a href="/2013/02/about-spec-support"><header>About spec/support</header></a>
+ <small>02 Feb 2013</small><br>
+ <p>I&#8217;m going to expand on a tweet I wrote this morning:</p>
+<blockquote class='twitter-tweet'><p>Thinking more and more that spec/support is an anti-pattern. I don’t want everything required for every test.</p>&mdash; Ryan Bigg (@ryanbigg) <a href='https://twitter.com/ryanbigg/status/297497422396026881'>February 2, 2013</a></blockquote>
+<p>I came to this thought when I was working on sharing testing support code between an engine and an application, for an example in Chapter 4 of <a href='https://leanpub.com/multi-tenancy-rails'>Multitenancy with Rails</a>. What I had originally was a file in <code>spec/support</code> called <code>SubdomainHelpers</code>, defined like this:</p>
-<p>The idea for the book has been around for a while. A couple of friends (<a href='https://github.com/parndt'>Phil Arndt</a>, <a href='https://github.com/knewter'>Josh Adams</a>, <a href='https://github.com/robyurkowski'>Rob Yurkowski</a> and <a href='https://github.com/GeekOnCoffee'>Andrew Hooker</a>) and I had been talking in our secret IRC back channel about what a more advanced Rails book might cover. Through I don&#8217;t know what process, we came up with this idea and I&#8217;m putting it into book form.</p>
+<pre><code>module SubdomainHelpers
+ def within_account_subdomain(&amp;block)
+ context &quot;within a subdomain&quot; do
+ let(:subdomain_url) { &quot;http://#{account.subdomain}.example.com&quot; }
+ before { Capybara.default_host = subdomain_url }
+ after { Capybara.default_host = &quot;http://example.com&quot; }
+ yield
+ end
+ end
+end</code></pre>
-<p>For now, all the book is covering is what we&#8217;re building, which is a hosted forum application, how to build a foundation for the subscriptions engine and then how we&#8217;re going to accomplish the database scoping necessary to separate the accounts&#8217; data.</p>
+<p>This module is then used to extend the RSpec <code>describe</code> blocks, like this</p>
-<p>The engine is what the book&#8217;s application is going to heavily rely on. This foundation building deals with adding things like accounts which have subdomains, and then authenticating users for those accounts using Warden, and not Devise. To find out why, you&#8217;re going to have to read it.</p>
+<pre><code>describe &quot;User sign in&quot; do
+ extend SubdomainHelpers
+ ...
+end</code></pre>
-<p>The chapter on scoping first of all covers using a database field, which is the typical way that people have been dealing with this problem for years, and then covers the &#8220;new&#8221; way of doing it: by using PostgreSQL schemas and the <code>apartment</code> gem.</p>
+<p>And then we can call <code>within_account_subdomain</code> whenever we need it.</p>
+<hr />
+<p>My problem with this is that this file is required <em>all the damn time</em>, even in tests which don&#8217;t use Capybara. The culprit is this default line in <code>spec/spec_helper.rb</code></p>
-<p>The next chapter, Chapter 4, will cover building the application which will combine both the subscriptions engine we build in Chapter 2, as well as the <a href='https://github.com/radar/forem'>Forem</a> forum engine that the aforementioned folk and I build and maintain.</p>
+<pre><code>Dir[File.dirname(__FILE__) + &quot;/support/**/*.rb&quot;].each {|f| require f }</code></pre>
-<p>Chapter 5 will cover subscriptions, where each account could be subscribed to the application for an amount such as $29/month and that allows them to create 5 forums. That sort of thing. It&#8217;ll also cover taking payments for those subscriptions using Stripe&#8217;s wonderful API, and then what to do if somebody decides to do a dodgy.</p>
+<p>This line is used for requiring all the files in <code>spec/support</code> so that you don&#8217;t have to. Seems like a good idea, but isn&#8217;t once you have a ton of things in <code>spec/support</code>.</p>
-<p>Testing (with RSpec and Capybara) is throughout, just like with Rails 3 in Action.</p>
+<p>Making it easy to require the file defining <code>SubdomainHelpers</code> in both the engine and the application involves moving the helper in to the <code>lib</code> directory of the engine, and then requiring that file in the appropriate places:</p>
-<p>So if you&#8217;re looking for a book that covers all of the above, please <a href='https://leanpub.com/multi-tenancy-rails'>buy a copy of Multitenancy with Rails</a> <em>right now</em>.</p>
+<pre><code>require &#39;subscribem/testing_support/subdomain_helpers&#39;</code></pre>
+
+<p>Even if we <em>weren&#8217;t</em> using an engine and an application and just had the application, I would much rather just be requiring just the files I need for a test, like this:</p>
+
+<pre><code>require &#39;support/subdomain_helpers&#39;</code></pre>
+
+<p>Than having the full range of <code>spec/support</code> files loaded all at once on the off chance a spec might need it. I wouldn&#8217;t expect this to <em>dramatically</em> increase a spec suite&#8217;s run time, but it&#8217;s got to be helping somewhat.</p>
</article>
</div>
@@ -56,6 +78,8 @@ <h1 align='center'>The Life of a Radar</h1>
<h2>25 back</h2>
<ul>
+ <li><a href="/2013/01/multitenancy-with-rails">Multitenancy with Rails</a><abbr>21 Jan 2013</abbr></li>
+
<li><a href="/2013/01/a-story-about-scaffolding">A story about scaffolding</a><abbr>07 Jan 2013</abbr></li>
<li><a href="/2012/11/no-more-writing-for-manning">No more writing for Manning</a><abbr>12 Nov 2012</abbr></li>
@@ -104,8 +128,6 @@ <h1 align='center'>The Life of a Radar</h1>
<li><a href="/2011/10/leaving-chicago">Leaving Chicago</a><abbr>02 Oct 2011</abbr></li>
- <li><a href="/2011/09/learning-and-asking">Learning and Asking</a><abbr>07 Sep 2011</abbr></li>
-
</ul>
<center><a href='/blogography.html'>The Complete Blogography</a></center>
</div>
Please sign in to comment.
Something went wrong with that request. Please try again.