Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Testing Ruby
Search
Emily Hyland
July 05, 2012
Programming
8
620
Testing Ruby
A fairly high-level intro to testing Ruby using RSpec, Factory Girl, and Autotest.
Emily Hyland
July 05, 2012
Tweet
Share
More Decks by Emily Hyland
See All by Emily Hyland
Programming for Humans
duien
0
54
Git: an introduction
duien
3
180
Other Decks in Programming
See All in Programming
競馬で学ぶ機械学習の基本と実践 / Machine Learning with Horse Racing
shoheimitani
0
160
アーキテクチャと考える迷子にならない開発者テスト
irof
2
160
CSC509 Lecture 09
javiergs
PRO
0
290
Verilator + Rust + gRPC と Efinix の RISC-V でAIアクセラレータをAIで作ってる話 RTLを語る会(18) 2025/11/08
ryuz88
0
330
Core MIDI を勉強して作曲用の電子ピアノ作ってみた!
hypebeans
0
100
なんでRustの環境構築してないのにRust製のツールが動くの? / Why Do Rust-Based Tools Run Without a Rust Environment?
ssssota
15
48k
歴史から学ぶ「Why PHP?」 PHPを書く理由を改めて理解する / Learning from History: “Why PHP?” Rediscovering the Reasons for Writing PHP
seike460
PRO
0
140
ネストしたdata classの面倒な更新にさようなら!Lensを作って理解するArrowのOpticsの世界
shiita0903
1
290
例外処理を理解して、設計段階からエラーを見つけやすく、起こりにくく #phpconfuk
kajitack
12
5.7k
Blazing Fast UI Development with Compose Hot Reload (droidcon London 2025)
zsmb
0
500
仕様がそのままテストになる!Javaで始める振る舞い駆動開発
ohmori_yusuke
2
1.1k
Vueのバリデーション、結局どれを選べばいい? ― 自作バリデーションの限界と、脱却までの道のり ― / Which Vue Validation Library Should We Really Use? The Limits of Self-Made Validation and How I Finally Moved On
neginasu
3
1.8k
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
84
9.3k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
24
1.5k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Scaling GitHub
holman
463
140k
YesSQL, Process and Tooling at Scale
rocio
174
15k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Thoughts on Productivity
jonyablonski
73
4.9k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
8k
Faster Mobile Websites
deanohume
310
31k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
36
6.1k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Transcript
TESTING RUBY USING RSPEC WITH FACTORY GIRL AND AUTOTEST Thursday,
July 5, 12
Why Test? Ensure your code is correct Refactor with confidence
Encourages lots of good practices Reference for how code works Thursday, July 5, 12
RUBY — TESTING Thursday, July 5, 12
THE EMILY WAY Thursday, July 5, 12
The Basics Write your test first Test behavior, not implementation
“You ain’t gonna need it” Thursday, July 5, 12
Test First Test-Driven Development Figure out requirements before you start
writing code Interface before implementation Thursday, July 5, 12
RED GREEN REFACTOR START Thursday, July 5, 12
Test Behavior Behavior-Driven Development Unit tests are sentences starting with
“it should” Use mocks for outside collaborators Changing the implementation shouldn’t break the test Thursday, July 5, 12
YAGNI Write only as much code as you need Thursday,
July 5, 12
YAGNI Write only as much code as you need THIS
IS SURPRISINGLY HARD Thursday, July 5, 12
RSPEC Thursday, July 5, 12
Why RSpec? Tests are very easy to read Syntax encourages
good practices Specify behavior instead of verifying state Tests as documentation Tests are more expressive and more maintainable Thursday, July 5, 12
describe Array do context "when empty" do
subject { Array.new } it { should be_empty } its(:first){ should be_nil } its(:length){ should == 0 } end end Basic Syntax Thursday, July 5, 12
More Syntax let(:user){ User.new } before{ set_current_user(user) } it "should
be reasonable" do "foo".should_not eq("bar") end it "should be magic" do pending "invent magic" end Thursday, July 5, 12
Shared Examples shared_examples "collections" do | klass| it "is
empty when first created" do klass.new.should be_empty end end describe Array do include_examples "collections", Array end Thursday, July 5, 12
Matchers it.should eq(expected) it.should == expected it.should be(expected) it.should equal(expected)
it.should be > minimum it.should be_within(x).of(y) Thursday, July 5, 12
Predicate Matchers it.should be_a_kind_of(klass) it.should be_true it.should be_empty it.should be_present
it.should be_* Thursday, July 5, 12
Expect Matchers expect { ... }.to raise_error expect { ...
}.to throw_symbol expect { ... }.to yield_control expect { ... }.to change{ it } Thursday, July 5, 12
On Rails Different file layout than with Test::Unit Directories for
model, controller, helper, and view specs Lots of Rails-specific matchers, etc. Thursday, July 5, 12
Model Classic unit test Test each model individually Ideally, isolate
from the database Check validations, but indirectly Add a context for each non-trivial method Thursday, July 5, 12
Controller Did you get the right response code? Did the
expected redirect happen? Were the correct instance variables set? Were the right flash messages displayed? Thursday, July 5, 12
Legacy Write tests for what you have before you change
it Write a failing test before you fix a bug Don’t try to do it all at once Thursday, July 5, 12
FACTORY GIRL Thursday, July 5, 12
Why Factories? Fixtures quickly get hard to maintain “What did
I call the fixture for my admin user without an email?” Create the right object when you need it Use templates to keep it DRY Thursday, July 5, 12
Syntax FactoryGirl.define do factory :user do
name "John Doe" factory :admin do admin true end end end FactoryGirl.build(:user) Thursday, July 5, 12
AUTOTEST Thursday, July 5, 12
Why Autotest? Never forget to run your tests again Get
nearly instant notification when you break something Run the right tests at the right time Thursday, July 5, 12
AND FINALLY... Thursday, July 5, 12
DO Write your tests first Use contexts Use shared example
groups Test your edge cases Thursday, July 5, 12
DON’T Test the framework Test the implementation Get too clever
Thursday, July 5, 12