Use Shoulda's validate_uniqueness_of matcher correctly
Works without requiring an initial record in modern versions.
This raises "Could not find first Keyword":
describe Keyword do
it { should validate_uniqueness_of(:text) }
end
Do this instead:
describe Keyword do
it 'should have a unique #text' do
Keyword.make
should validate_uniqueness_of(:text)
end
end
This is the intended behavior.
Related cards:
You can use any RSpec matcher to match arguments of method calls
RSpec lets you define the arguments with which you expect a method to be invoked:
subject.should_receive(:say).with('hello')
Sometimes you don't care about the exact arguments. For such cases RSpec comes with [argument constraints](https...
RSpec: Composing a custom matcher from existing matchers
When you find similar groups of expect calls in your tests, you can improve readability by extracting the group into its own matcher. RSpec makes this easy by allowing matchers to call other matchers.
Example
The following test checks that ...
RSpec: Leverage the power of Capybara Finders and Matchers for view specs
View specs are a powerful tool to test several rendering paths by their cases instead of using a more costing feature spec. This is especially useful because they become quite co...
RSpec: Expect one of multiple matchers to match
RSpec let's you chain a matcher with .or. The expectation will then pass if at least one matcher matches:
expect(color).to eq("red").or eq("green")
Real-world example
A real-world use case would be to test if th...
Use capybara and not rspec matchers
One rule of thumb I try to follow in capybara tests is using capybara matchers and not plain rspec matchers.
One example:
visit(some_page)
text_field = find('.textfield')
expect(text_field['value']).to match /pattern/
This can work,...
RSpec's hash_including matcher does not support nesting
You can not use the hash_including argument matcher with a nested hash:
describe 'user' do
let(:user) { {id: 1, name: 'Foo', thread:...
Usage of RSpec's raise_error
Never use raise_error without specifying the Error you expect.
expect { do_a_lot_of_complicated_stuff }.to raise_error
will be green if you make any error in programming. E.g. a simple typo would make the test above green. The block will c...
Using RSpec's late resolving of "let" variables for cleaner specs
Consider the following:
describe '#something' do
context 'with lots of required arguments' do
it 'should work' do
subject.something(:foo => 'foo', :bar => 'bar', :baz => 'baz').should == 'Hello world'
end
...
Taking advantage of RSpec's "let" in before blocks
Inside before :each blocks you can refer to variables that you introduce via let later on.
They do not need to be defined ahead of your before block and can be different for individual sections.
It works just like that:
describe Use...
Daring Fireball: New iPhone Developer Agreement Bans the Use of Adobe's Flash-to-iPhone Compiler
Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Application...