The suite of tests is not there to satisfy the QA groups, it is not there to prove to other people that our code works. The suite of tests is there so that we can refactor. So that when we bring the code up to our screen then we're not afraid of it. @unclebobmartin
- Cheat Sheet, the whole thing compressed into 3 pages https://gist.github.com/1852758
- RSpec Documentation (sadly not complete)
- https://www.relishapp.com/rspec/rspec-core/docs
- Complete API http://rspec.info/
- Awesome Blogpost http://areyoufuckingcoding.me/2012/03/25/nothing-really-matters/
- 10 min presentation (slides) http://blog.bandzarewicz.com/slides/krug-the-perfect-rspec/#34
- Rspec Best Practices
- http://thinkvitamin.com/code/ruby-on-rails/an-introduction-to-rspec/
- http://bitfluxx.com/2011/05/23/some-rspec-tips-and-best-practices.html
- http://kpumuk.info/ruby-on-rails/my-top-7-rspec-best-practices/
- http://eggsonbread.com/2010/03/28/my-rspec-best-practices-and-tips/
- http://blog.carbonfive.com/2010/10/21/rspec-best-practices/
This is the basic DSL all our specs are written in. Provides expectations to set on a feature, and then to code to it.
https://github.com/jnicklas/capybara Capybara provides some view testing for requests, also full browsers test with a headless webkit.
within("#session") do
fill_in 'Login', :with => '[email protected]'
fill_in 'Password', :with => 'password'
end
click_link 'Sign in'
https://github.com/thoughtbot/shoulda-matchers A couple of matchers to test Rails / ActiveModel specific behaviour
describe Post do
it { should belong_to(:user) }
it { should have_many(:tags).through(:taggings) }
end
describe User do
it { should have_many(:posts) }
end
http://thinkvitamin.com/code/ruby-on-rails/an-introduction-to-rspec/ create objects on fly, makes testing with real objects much easier, replaces mocking, but it's a bit slow.
bundle exec guard
Guard runs your spec in the background, it's sort-of smart and tries to run only the specs that are affected by your code changes.
Pry is an awesome IRB / Rails console replacement, that lets you dive into objects, manipulate it's code at runtime and does line-by-line debugging. It also offers hooks to be triggered by your rails server / specs.
put
binding.pry-remote
somewhere in your code, run it and start
pry-remote
.
- Cucumber, we use RSpec for our Request / Integration / Acceptance tests as well.
- Mocks, Mocha: Mocking let's you test only the features you are actually working on. However this has become very unpopular in the past year or two. People tended to mock so much, they weren't actually testing anything useful anymore.
- Webrat, obsolete since Capybara
- autotest(surpassed by guard)