<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: My (new) favourite RSpec pattern</title>
	<atom:link href="http://blog.thefrontiergroup.com.au/2012/06/my-new-favourite-rspec-pattern/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.thefrontiergroup.com.au/2012/06/my-new-favourite-rspec-pattern/</link>
	<description>Your peek inside the collective mind of The Frontier Group</description>
	<lastBuildDate>Fri, 17 May 2013 04:46:37 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
	<item>
		<title>By: remi</title>
		<link>http://blog.thefrontiergroup.com.au/2012/06/my-new-favourite-rspec-pattern/comment-page-1/#comment-3891</link>
		<dc:creator>remi</dc:creator>
		<pubDate>Wed, 04 Jul 2012 02:55:08 +0000</pubDate>
		<guid isPermaLink="false">http://blog.thefrontiergroup.com.au/?p=1943#comment-3891</guid>
		<description>As a general rule, tests should *NOT* be DRY.  You should only DRY your tests when they become difficult to maintain, and you should do your best to keep them verbose, descriptive, and easy to understand.  Reading a spec is like reading a book.  They should tell a story.  Specs are DOCUMENTATION.

IMHO, this should be considered an antipattern.  It will come back to bite you.

This pattern defines attributes which are then overridden in #it examples or nested contexts.  So, when someone tries to actually UNDERSTAND this spec to figure out what it does, they have to walk ALL the way up a tree of defined #let (overriding attributes) to figure out what&#039;s going on.  This is VERY confusing.  Just write out the code in #it blocks (and move *some* redundant code into #before blocks) and the spec will be easier to understand and therefore maintain (which will increase your overall productivity).</description>
		<content:encoded><![CDATA[<p>As a general rule, tests should *NOT* be DRY.  You should only DRY your tests when they become difficult to maintain, and you should do your best to keep them verbose, descriptive, and easy to understand.  Reading a spec is like reading a book.  They should tell a story.  Specs are DOCUMENTATION.</p>
<p>IMHO, this should be considered an antipattern.  It will come back to bite you.</p>
<p>This pattern defines attributes which are then overridden in #it examples or nested contexts.  So, when someone tries to actually UNDERSTAND this spec to figure out what it does, they have to walk ALL the way up a tree of defined #let (overriding attributes) to figure out what&#8217;s going on.  This is VERY confusing.  Just write out the code in #it blocks (and move *some* redundant code into #before blocks) and the spec will be easier to understand and therefore maintain (which will increase your overall productivity).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: This Week in Ruby: Rails 4 Sneak Peeks, A Gist Drama, and a CoffeeScript Book (by a Rubyist!)</title>
		<link>http://blog.thefrontiergroup.com.au/2012/06/my-new-favourite-rspec-pattern/comment-page-1/#comment-3888</link>
		<dc:creator>This Week in Ruby: Rails 4 Sneak Peeks, A Gist Drama, and a CoffeeScript Book (by a Rubyist!)</dc:creator>
		<pubDate>Fri, 29 Jun 2012 13:32:14 +0000</pubDate>
		<guid isPermaLink="false">http://blog.thefrontiergroup.com.au/?p=1943#comment-3888</guid>
		<description>[...] My (new) Favourite RSpec Pattern Jordan Maguire shares an interesting RSpec technique and there&#039;s some interesting debate in the comments. It seems popular, though Geoffrey Grosenbach raises doubts about its readability. [...]</description>
		<content:encoded><![CDATA[<p>[...] My (new) Favourite RSpec Pattern Jordan Maguire shares an interesting RSpec technique and there&#039;s some interesting debate in the comments. It seems popular, though Geoffrey Grosenbach raises doubts about its readability. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmytrii Nagirniak</title>
		<link>http://blog.thefrontiergroup.com.au/2012/06/my-new-favourite-rspec-pattern/comment-page-1/#comment-3887</link>
		<dc:creator>Dmytrii Nagirniak</dc:creator>
		<pubDate>Fri, 29 Jun 2012 00:54:04 +0000</pubDate>
		<guid isPermaLink="false">http://blog.thefrontiergroup.com.au/?p=1943#comment-3887</guid>
		<description>I would instead use `its` construct: https://github.com/dnagir/its

subject { create :vehicle, attributes }
let(:attributes) { {name: &#039;Dmytrii&#039; } }
its(:to_s) { should == &#039;Dmytrii&#039; }

But that doesn&#039;t look too good either and then I would apply macro:

to_s_from_attributes({name: &#039;Dmytrii&#039;}) { should == &#039;Dmytrii&#039; }

Which would look similarly to https://gist.github.com/3014807#file_tax_spec.rb</description>
		<content:encoded><![CDATA[<p>I would instead use `its` construct: <a href="https://github.com/dnagir/its" rel="nofollow">https://github.com/dnagir/its</a></p>
<p>subject { create :vehicle, attributes }<br />
let(:attributes) { {name: &#8216;Dmytrii&#8217; } }<br />
its(:to_s) { should == &#8216;Dmytrii&#8217; }</p>
<p>But that doesn&#8217;t look too good either and then I would apply macro:</p>
<p>to_s_from_attributes({name: &#8216;Dmytrii&#8217;}) { should == &#8216;Dmytrii&#8217; }</p>
<p>Which would look similarly to <a href="https://gist.github.com/3014807#file_tax_spec.rb" rel="nofollow">https://gist.github.com/3014807#file_tax_spec.rb</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: This Week in Ruby: A Gist Drama, A New CoffeeScript Book (by a Rubyist!), and Other Handy Things</title>
		<link>http://blog.thefrontiergroup.com.au/2012/06/my-new-favourite-rspec-pattern/comment-page-1/#comment-3886</link>
		<dc:creator>This Week in Ruby: A Gist Drama, A New CoffeeScript Book (by a Rubyist!), and Other Handy Things</dc:creator>
		<pubDate>Fri, 29 Jun 2012 00:25:31 +0000</pubDate>
		<guid isPermaLink="false">http://blog.thefrontiergroup.com.au/?p=1943#comment-3886</guid>
		<description>[...] My (new) Favourite RSpec Pattern Jordan Maguire shares an interesting RSpec technique and there&#039;s some interesting debate in the comments. It seems popular, though Geoffrey Grosenbach raises doubts about its readability. [...]</description>
		<content:encoded><![CDATA[<p>[...] My (new) Favourite RSpec Pattern Jordan Maguire shares an interesting RSpec technique and there&#039;s some interesting debate in the comments. It seems popular, though Geoffrey Grosenbach raises doubts about its readability. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Deville</title>
		<link>http://blog.thefrontiergroup.com.au/2012/06/my-new-favourite-rspec-pattern/comment-page-1/#comment-3885</link>
		<dc:creator>Jeff Deville</dc:creator>
		<pubDate>Thu, 28 Jun 2012 19:54:28 +0000</pubDate>
		<guid isPermaLink="false">http://blog.thefrontiergroup.com.au/?p=1943#comment-3885</guid>
		<description>@iain, I was at GoRuCo as well, and asked him about exactl this, and he said that this wasn&#039;t really what he was condemning, and seemed concerned that I&#039;d gotten that impression.  I think he was just pointing out that the code could be confusing if you don&#039;t realize that before blocks are run from top to bottom.    

I really REALLY wanted to dig into this stuff further with him, but the next session started and I didn&#039;t get a chance to to get any further than that.  I don&#039;t think the let/let! syntax would really be useful were this use case not in mind though.

That said, he seems to stick w/ duplication in his it blocks.

Regarding FactoryGirl, I agree w/ Richard, though I tend to use traits to try and keep things organized.

PS - When you find that your specs are getting slow (if you only test 1 thing per &#039;it&#039; block as I do), look into the Machinery gem. You lose a lot of the beautiful expressiveness, but you reclaim a lot of the speed.</description>
		<content:encoded><![CDATA[<p>@iain, I was at GoRuCo as well, and asked him about exactl this, and he said that this wasn&#8217;t really what he was condemning, and seemed concerned that I&#8217;d gotten that impression.  I think he was just pointing out that the code could be confusing if you don&#8217;t realize that before blocks are run from top to bottom.    </p>
<p>I really REALLY wanted to dig into this stuff further with him, but the next session started and I didn&#8217;t get a chance to to get any further than that.  I don&#8217;t think the let/let! syntax would really be useful were this use case not in mind though.</p>
<p>That said, he seems to stick w/ duplication in his it blocks.</p>
<p>Regarding FactoryGirl, I agree w/ Richard, though I tend to use traits to try and keep things organized.</p>
<p>PS &#8211; When you find that your specs are getting slow (if you only test 1 thing per &#8216;it&#8217; block as I do), look into the Machinery gem. You lose a lot of the beautiful expressiveness, but you reclaim a lot of the speed.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bernd Ustorf</title>
		<link>http://blog.thefrontiergroup.com.au/2012/06/my-new-favourite-rspec-pattern/comment-page-1/#comment-3884</link>
		<dc:creator>Bernd Ustorf</dc:creator>
		<pubDate>Thu, 28 Jun 2012 19:22:25 +0000</pubDate>
		<guid isPermaLink="false">http://blog.thefrontiergroup.com.au/?p=1943#comment-3884</guid>
		<description>Yup... this definitely cleans up the setup code.</description>
		<content:encoded><![CDATA[<p>Yup&#8230; this definitely cleans up the setup code.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Justin Ko</title>
		<link>http://blog.thefrontiergroup.com.au/2012/06/my-new-favourite-rspec-pattern/comment-page-1/#comment-3883</link>
		<dc:creator>Justin Ko</dc:creator>
		<pubDate>Thu, 28 Jun 2012 19:18:12 +0000</pubDate>
		<guid isPermaLink="false">http://blog.thefrontiergroup.com.au/?p=1943#comment-3883</guid>
		<description>David Chelimsky would have done it like this:

describe &quot;#to_s&quot;  
  it &#039;returns the &quot;name&quot; attribute&#039; do
    vehicle = FactoryGirl.create(:vehicle, name: &#039;Carzilla&#039;, type_of_sale: &#039;New&#039;)
    vehicle.to_s.should eq &#039;Carzilla&#039;
  end
end</description>
		<content:encoded><![CDATA[<p>David Chelimsky would have done it like this:</p>
<p>describe &#8220;#to_s&#8221;<br />
  it &#8216;returns the &#8220;name&#8221; attribute&#8217; do<br />
    vehicle = FactoryGirl.create(:vehicle, name: &#8216;Carzilla&#8217;, type_of_sale: &#8216;New&#8217;)<br />
    vehicle.to_s.should eq &#8216;Carzilla&#8217;<br />
  end<br />
end</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Michael</title>
		<link>http://blog.thefrontiergroup.com.au/2012/06/my-new-favourite-rspec-pattern/comment-page-1/#comment-3881</link>
		<dc:creator>Richard Michael</dc:creator>
		<pubDate>Wed, 27 Jun 2012 20:55:23 +0000</pubDate>
		<guid isPermaLink="false">http://blog.thefrontiergroup.com.au/?p=1943#comment-3881</guid>
		<description>In the specific case of FactoryGirl, and depending on the attributes, test context and repetition, I like to lift this up into the Factory itself with either factory inheritance or traits.

This can even improve readability (indicative factory names) and also has the benefit of exposing that object &quot;type&quot; to other parts of the test suite, or even production (depending how you use FactoryGirl).

Aside, on the GoRuCo 2012 footage, can you can still watch the JustinTV &quot;live&quot; stream and just jump around in it.  I watched part of David&#039;s talk yesterday.</description>
		<content:encoded><![CDATA[<p>In the specific case of FactoryGirl, and depending on the attributes, test context and repetition, I like to lift this up into the Factory itself with either factory inheritance or traits.</p>
<p>This can even improve readability (indicative factory names) and also has the benefit of exposing that object &#8220;type&#8221; to other parts of the test suite, or even production (depending how you use FactoryGirl).</p>
<p>Aside, on the GoRuCo 2012 footage, can you can still watch the JustinTV &#8220;live&#8221; stream and just jump around in it.  I watched part of David&#8217;s talk yesterday.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: iain</title>
		<link>http://blog.thefrontiergroup.com.au/2012/06/my-new-favourite-rspec-pattern/comment-page-1/#comment-3880</link>
		<dc:creator>iain</dc:creator>
		<pubDate>Wed, 27 Jun 2012 08:41:11 +0000</pubDate>
		<guid isPermaLink="false">http://blog.thefrontiergroup.com.au/?p=1943#comment-3880</guid>
		<description>BTW: There was a follow up on this talk on GoRuCo 2012. The first videos of this conference are already on confreaks, but the one by Chelimsky not yet. I watched the talk live. He addresses exactly the style you mentioned here.</description>
		<content:encoded><![CDATA[<p>BTW: There was a follow up on this talk on GoRuCo 2012. The first videos of this conference are already on confreaks, but the one by Chelimsky not yet. I watched the talk live. He addresses exactly the style you mentioned here.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jordan Maguire</title>
		<link>http://blog.thefrontiergroup.com.au/2012/06/my-new-favourite-rspec-pattern/comment-page-1/#comment-3879</link>
		<dc:creator>Jordan Maguire</dc:creator>
		<pubDate>Wed, 27 Jun 2012 08:16:33 +0000</pubDate>
		<guid isPermaLink="false">http://blog.thefrontiergroup.com.au/?p=1943#comment-3879</guid>
		<description>Thanks for the link Iain I&#039;ll have a watch when I get some time tonight</description>
		<content:encoded><![CDATA[<p>Thanks for the link Iain I&#8217;ll have a watch when I get some time tonight</p>
]]></content:encoded>
	</item>
</channel>
</rss>
