<?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: Techniques for Exhaustively Testing a Rails App</title>
	<atom:link href="http://www.pervasivecode.com/blog/2008/08/23/techniques-for-exhaustively-testing-a-rails-app/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.pervasivecode.com/blog/2008/08/23/techniques-for-exhaustively-testing-a-rails-app/</link>
	<description>Jamie Flournoy's Software Development Blog</description>
	<lastBuildDate>Wed, 02 Nov 2011 15:50:40 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Jamie Flournoy</title>
		<link>http://www.pervasivecode.com/blog/2008/08/23/techniques-for-exhaustively-testing-a-rails-app/comment-page-1/#comment-9840</link>
		<dc:creator>Jamie Flournoy</dc:creator>
		<pubDate>Sun, 24 Aug 2008 21:41:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.pervasivecode.com/blog/2008/08/23/techniques-for-exhaustively-testing-a-rails-app/#comment-9840</guid>
		<description>Factory Girl doesn&#039;t solve any problems I have right now, but it does look interesting for that time somewhere down the road when I get sick of fixtures and just start moving things into in-memory objects as much as possible.

Shoulda was already on my list to check out soonish, and I do like the fact that unlike RSpec it integrates easily with existing TestUnit tests and setup infrastructure.

I agree, rcov 100% coverage &lt; fully tested. But that means if you have &lt; 100% coverage, you are way way &lt; fully tested, so that&#039;s a good place to start for guidance regarding stuff you&#039;ve overlooked in existing tests.</description>
		<content:encoded><![CDATA[<p>Factory Girl doesn&#8217;t solve any problems I have right now, but it does look interesting for that time somewhere down the road when I get sick of fixtures and just start moving things into in-memory objects as much as possible.</p>
<p>Shoulda was already on my list to check out soonish, and I do like the fact that unlike RSpec it integrates easily with existing TestUnit tests and setup infrastructure.</p>
<p>I agree, rcov 100% coverage &lt; fully tested. But that means if you have &lt; 100% coverage, you are way way &lt; fully tested, so that&#8217;s a good place to start for guidance regarding stuff you&#8217;ve overlooked in existing tests.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dr. Mark</title>
		<link>http://www.pervasivecode.com/blog/2008/08/23/techniques-for-exhaustively-testing-a-rails-app/comment-page-1/#comment-9825</link>
		<dc:creator>Dr. Mark</dc:creator>
		<pubDate>Sun, 24 Aug 2008 03:19:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.pervasivecode.com/blog/2008/08/23/techniques-for-exhaustively-testing-a-rails-app/#comment-9825</guid>
		<description>Aloha,

Good article. I suggest that you consider using factories instead of fixtures. We switched to Factory Girl a while ago and it really does work better than fixtures. Being able to update one place (the factory+test) when a model changes is much easier than tracking down all of the places in the test data that require updating. 

Also, consider using Shoulda. I know that you dislike the testing DSLs but Shoulda has several macros that really make testing the basic things easier. Within 20 lines of code you can test all of your validations, relationships, etc. Then the bulk of your test suite is left to test the hard stuff. Plus, it works well with the standard Test Unit.

As to testing the views, Selenium works but it takes a LOT of work to keep it up to date with your views unless you are following a test first approach. I must admit that I can&#039;t force myself to write tests first. We follow a test-same approach. Meaning that you can&#039;t commit the code until there are corresponding tests. 

I am sure you know this, but don&#039;t rely too heavily on a 100% score from rcov. Having a 100% coverage does NOT mean that your code is fully tested because it doesn&#039;t follow all branches/paths through your code. Testing the edge cases is where the bulk of our time is spent in testing. There have been several good articles on the topic recently.

Best of luck!

DrMark</description>
		<content:encoded><![CDATA[<p>Aloha,</p>
<p>Good article. I suggest that you consider using factories instead of fixtures. We switched to Factory Girl a while ago and it really does work better than fixtures. Being able to update one place (the factory+test) when a model changes is much easier than tracking down all of the places in the test data that require updating. </p>
<p>Also, consider using Shoulda. I know that you dislike the testing DSLs but Shoulda has several macros that really make testing the basic things easier. Within 20 lines of code you can test all of your validations, relationships, etc. Then the bulk of your test suite is left to test the hard stuff. Plus, it works well with the standard Test Unit.</p>
<p>As to testing the views, Selenium works but it takes a LOT of work to keep it up to date with your views unless you are following a test first approach. I must admit that I can&#8217;t force myself to write tests first. We follow a test-same approach. Meaning that you can&#8217;t commit the code until there are corresponding tests. </p>
<p>I am sure you know this, but don&#8217;t rely too heavily on a 100% score from rcov. Having a 100% coverage does NOT mean that your code is fully tested because it doesn&#8217;t follow all branches/paths through your code. Testing the edge cases is where the bulk of our time is spent in testing. There have been several good articles on the topic recently.</p>
<p>Best of luck!</p>
<p>DrMark</p>
]]></content:encoded>
	</item>
</channel>
</rss>

