Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Fetching contributors…
Cannot retrieve contributors at this time
250 lines (169 sloc) 13.2 KB
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="">
<title><![CDATA[Category: rails_tips | Entreprevelopment adventures]]></title>
<link href="" rel="self"/>
<link href=""/>
<name><![CDATA[Luisa Lima]]></name>
<generator uri="">Octopress</generator>
<title type="html"><![CDATA[How I test part II - testing models]]></title>
<link href=""/>
<content type="html"><![CDATA[<h2>Testing models</h2>
<p>From <a href="">rails guides</a>:</p>
<p>"Ideally, you would like to include a test for everything which could possibly break. It’s a good practice to have at least one test for each of your validations and at least one test for every method in your model."</p>
<p>Which leads me to...</p>
<h2>Why I use shoulda</h2>
<p>I think that the best thing is just to take a peek at <a href="">The shoulda cheat sheets</a>.</p>
<p>You actually get a guide of what to test by looking at the cheat sheet! It's too bad that it's not up to date (actually I think that the whole site is not up to date -- even the gem doesn't work anymore, which I think is too bad :-( )</p>
<p>Furthermore, it's great for lazy people and it's definitely easier on the eyes. Just check the following example:</p>
<script src="">
<p><div><script src=''></script>
<noscript><pre><code># without shoulda... tons of code :-)
it &quot;should belong to person&quot; do
Model.reflect_on_association(:person).macro.should == :belongs_to
# with shoulda... one-liner!
it{should belong_to(:person)}
<p>Convinced? ;-)</p>
<h2>What I test exactly with shoulda</h2>
<p>I go through the whole list of shoulda macros for models, and I just use and abuse them. Since the cheat sheet is not up to date, I created a new one (just for models for now) at:</p>
<p><div><script src=''></script>
<noscript><pre><code># updated from the original @
# just a subset -- models -- is included here. I'll update this, and create cheat sheets for others, as I go along.
# I marked the ones I added with NEW and also added the links to the corresponding code, as I think it's useful.
# Any comments/corrections are welcome!
# ================= Data and Associations =======================
it { should_not have_db_column(:admin).of_type(:boolean) }
it { should have_db_column(:salary).
with_options(:precision =&gt; 10, :scale =&gt; 2) }
it { should have_readonly_attributes(:password) }
it { should belong_to(:parent) }
it { should have_db_index(:id) } # NEW
it { should have_many(:friends) }
it { should have_many(:enemies).through(:friends) }
it { should have_many(:enemies).dependent(:destroy) }
it { should have_one(:god) }
it { should have_and_belong_to_many(:posts) }
it {should accept_nested_attributes_for(:user)} # NEW
# ================== Validation Matchers ============================
it { should validate_uniqueness_of(:keyword) }
it { should validate_uniqueness_of(:keyword).with_message(/dup/) }
it { should validate_uniqueness_of(:email).scoped_to(:name) }
it { should validate_uniqueness_of(:email).
scoped_to(:first_name, :last_name) }
it { should validate_uniqueness_of(:keyword).case_insensitive }
it { should validate_presence_of(:name) }
it { should validate_presence_of(:name).
with_message(/is not optional/) }
it { should validate_numericality_of(:age) }
it { should validate_format_of(:name).
with_message(/is not optional/) }
it { should validate_format_of(:name).
with_message(/is not optional/) }
it { should validate_acceptance_of(:eula) }
it { should ensure_length_of(:password).
is_at_most(20) }
it { should ensure_length_of(:name).
with_short_message(/not long enough/) }
it { should ensure_length_of(:ssn).
with_message(/is invalid/) }
it { should ensure_inclusion_of(:age).in_range(0..100) }
it { should_not allow_mass_assignment_of(:password) }
it { should allow_mass_assignment_of(:first_name) }
it { should validate_format_of(:first_name).with(&quot;Carl&quot;) }
it { should validate_confirmation_of(:password) } # NEW</code></pre></noscript></div>
<p>Yes, it's a bit tedious. But (1) you make sure that you are actually testing all these details, which is extremely useful when you are constantly refactoring your code, and (2) it's not that slow with the multiple cursors of Sublime Text 2. You just need to have a scaffold.</p>
<h2>What I test without shoulda</h2>
<p>Apart from model methods, is there that much to test without shoulda? I test:</p>
<li>Any model methods, extensively</li>
<li>Callbacks, extremely extensively</li>
<li>Some validations - but just to make sure I coded them right. See more of this perspective in <a href="">Testing model validations in rspec the short and sweet way</a></li>
<p>... and for now, that's about it.</p>
<h2>Regarding generating fake data</h2>
<p>Like I mentioned before, I do use FactoryGirl extensively. Maybe that means that <a href="">my models are complicated</a>? I don't know, but for now, I am sort of using good sense and stuff. Let's see what happens. I do use <a href="">Faker</a> as well. Come to think about it, will do a post on that eventually.</p>
<h2>Random issues in testing models</h2>
<p>When everything seems to be absolutely correct in the models and in the tests and you are still getting unexplainable errors, do restart guard. I already spent several hours messing around with the tests because guard didn't refresh the models. <a href="">There are automatic solutions</a>, but I didn't feel like hacking away the spork/guard configurations again... yet.</p>
<h2>Random resources</h2>
<li><p><a href="">Everyday Rails: How I learned to test my Rails applications, Part 3: Model specs</a> - this has a very nice overview of the actual steps required to test models. Now I just cheat using shoulda, but it's very nice and useful to get a</p></li>
<li><p><a href="">Testing model validations in rspec the short and sweet way</a> - it's a bit outdated, but describes how to test validations in a short way.</p></li>
<hr />
<p>Again, as I already mentioned, I am a beginner to rails and, consequently, in testing rails, so I might be doing/saying terribly wrong things. Any input is very much appreciated :-)</p>
<title type="html"><![CDATA[How I test - Part I: Environment]]></title>
<link href=""/>
<content type="html"><![CDATA[<p>Not that I am an authority in testing... this is just a compilation of the so-called "best practices" that I've been seeing around, as well as some extra tips from my (very limited) experience. I'd love to hear the feedback from more experienced people... I'm going to do several of these as I go along.</p>
<h2>Gems I use</h2>
<p>I test using <a href="">rspec</a> and <a href="">shoulda</a>, which dramatically reduces the size of the tests. But beware -- rspec is a DSL, and I think that I only got a bit more intuition on what I was exactly testing after doing some tests in Test::Unit. I also use <a href="">FactoryGirl</a> for setting up the test data, instead of fixtures. Last but not least, the <a href="">simplecov</a> gem is amazing, and although you shouldn't rely on it to determine when to stop testing, it really is good to get a (very precise) sense of what's covered and what's not in their beautiful html reports.</p>
<h2>General tips</h2>
<p>When all your tests are red for no apparent reason, it's because you were messing around with the db and then forgot to do</p>
<pre><code>rake db:test:clone</code></pre>
<p>Yup, the reason I am mentioning it here even though it seems completely obvious is because I am distracted and do that a lot... :-)</p>
<h2>Tips for running guard/spork in vagrant</h2>
<p>I use vagrant to keep my environment all neatly in one place. However, there are downsides. When running guard inside the guest OS, use</p>
<pre><code>bundle exec guard -p</code></pre>
<p>Otherwise, guard won't detect changes in the guest filesystem.</p>
<h2>FactoryGirl tips</h2>
<p>You can keep all factories in one file, for me that is more intuitive (and also, I don't have to keep opening files while I'm testing, it's all in one place.)</p>
<p>To try FactoryGirl methods in the console, run:</p>
<p>At least in my case, I would get a <a href="">factory not registered</a> error when I didn't do that.</p>
<h2>Better Errors</h2>
<p>Not exactly related to testing, but <a href="">this gem</a> has been a life changer! When there is an error, the standard error page gets replaced by a much better and useful error page, which has a full trace, the local and instance variables that are set at the time, and a terminal that you can use to inspect and make changes to the variables in the models and controllers in real time (or code whatever you want). I know I already mentioned it in another post, but I can't stress enough how cool this gem is!</p>
<p>In the next posts, I'll give an overview of how I test the models and controllers, which I only started testing this week!</p>
<title type="html"><![CDATA[Rails tip #2 - less Rspec in more color]]></title>
<link href=""/>
<content type="html"><![CDATA[<p>I usually have Guard running in the background with Spork, but when I'm writing tests I like to do it the old fashioned way and be able to do rspec some_test | less. The problem with that approach is that we get a monochrome version of our tests. In order to redirect the color in the pipe, edit spec_helper and add the following:</p>
<pre><code> # spec/spec_helper.rb
Rspec.configure do |config|
config.tty = true
config.color_enabled = true
# ... whatever configurations you might have here...
<p>And enjoy a more colorful life ;-)</p>
<title type="html"><![CDATA[Rails tip #1 - environment variables]]></title>
<link href=""/>
<content type="html"><![CDATA[<p>This isn't exactly my tip (well, since this is a learning / work in progress blog, none of them are), but when an article is already as comprehensive as this one, there's nothing left to say except:</p>
<p><a href="">Here's a very nice article on the options for setting environment variables in Rails</a></p>
<p>Why would you want to set environment variables in rails? There are some examples in the article, but for instance, setting passwords to access services. They should not be in any file (nor tracked in git), so that other people cannot access them. One way is to set Unix environment variables, the other way -- which actually sounds like a "cleaner way" of organizing things -- is to set them from Rails itself by taking the values from a yaml file.</p>
Jump to Line
Something went wrong with that request. Please try again.