I've used shoulda for a while, and I've read and played with rspec. I have not done an in depth compare and contrast. But it seems to me like there is some overlap between the two, but that they are not 1-1 replacements.
I am considering writing some unit tests in my rails system with rspec, without replacing all the existing tests that are written with shoulda. Just as a way to get the feel.
Is this a good idea? Can I gradually move from one to the other or am I asking for trouble?
Any clear cut advantages of one over the other that I should consider?
Thanks!
I have to argue against Chris's answer that they are alternatives. I use Shoulda and Rspec together in my Rails application, and they complement each other well.
This combo allows me to write concise one-line unit tests for recurring things like associations and validations, as well as the having the full rspec suite for more complex specs. You get the best of both worlds without any conflicts.
Check out the Shoulda README which shows how to install along side Rspec. It even says it provides "Test::Unit- and RSpec-compatible one-liners that test common Rails functionality. These tests would otherwise be much longer, more complex, and error-prone."
Edit (examples):
At the top of my specs, I always declare my Class relationship and validation tests which are concise and easy to read.
describe Component do
context 'relationships' do
it { should belong_to(:technology)}
it { should have_many(:system_components) }
it { should have_and_belong_to_many(:variables) }
it { should have_many(:images).dependent(:destroy) }
it { should have_many(:documents).dependent(:destroy) }
end
context 'validations' do
it { should validate_presence_of(:make) }
it { should validate_presence_of(:model) }
it { should ensure_length_of(:name).is_at_most(100) }
it { should validate_presence_of(:technology_id) }
end
end
Then the rest of my spec will have more complex tests where I am using mocks and stubs which come from Rspec.
rspec and shoulda are alternatives to each other. I started with shoulda, as well, and moving to rspec is as simple as s/context/describe/, s/should/it/, and you're off to the races. rspec has a bunch of tricks, various integrations, and more complex matchers, so I'm using it more these days myself.
One of my initial frustrations was that it was nearly impossible to find a tutorial that didn't assume Rails and Cucumber. Don't overthink it - there's a lot you can do with it, but you don't have to have a monster of a solution in place before you can use it.
Related
I'm looking for a convenient way to test validations of a Reform-based form object.
Are there any matchers (like shoulda matchers for testing ActiveModel::Validations) to test dry-validations? Is this even the way to go?
There is this: https://github.com/bloom-solutions/dry-validation-matchers
I've enjoyed using shoulda matchers in the past. It helps to greatly cut down on the repetitive code where you first create a valid object and then change the attribute affected by the validation to an invalid value to carry out the test.
In the end this is just a matter of taste.
I started reading a book about rSpec as my basic intro to testing my Rails app. I started writing tests like:
it 'is valid with a name' do
coaster = FactoryGirl.build(:coaster)
expect(coaster).to be_valid
end
But then someone pointed me at Shoulda and can now write tests like:
it { should validate_presence_of(:name) }
Note: I realise the two tests posted are not the same, merely just examples of each type.
What I need some clarification of is, is Shoulda an alternative to rSpec or is Shoulda an addon to it?
Which way would others go about this? The Shoulda tests seem simpler and shorter overall.
Basically any thoughts and comments would be helpful.
Shoulda just adds additional matchers to RSpec.
http://rubydoc.info/github/thoughtbot/shoulda-matchers/master/frames
The BDD style is exposed through expect, expect is more natural language assertions. First of all, notice that the expect require is just a reference to the expect value, whereas with the should require, the value is being executed. The should style extends each object with a should property which is called monkey patch in ruby. Here is a good article which explains and compares this two assertion mechanism.
I'd like to be able to use Rails' test fixture helpers in Cucumber, but the information provided on the Cucumber wiki seems... out of date at best: https://github.com/cucumber/cucumber/wiki/Fixtures (heading: Fixture Helper Methods)
Google has been less than helpful.
Is there a good way to do this?
Update: Tried using ActiveRecord::TestFixtures to no avail it seems like this is the class to do the job, but can't get it mixed into the World correctly
One of the reasons there's so little information on fixtures is that most rails developers are now all using Factory Girl to generate test data.
Factory Girl provides you mush more control over both the data that's generated (and when it's created), but it also allows you a lot more control of the associated model classes you inevitably will need.
After an hour of brain cramming, I was able to make it work.
Replace
fix = Fixtures.cached_fixtures(ActiveRecord::Base.connection, table_name)[fixture_symbol.to_s]
with
fix = Fixtures.cached_fixtures(ActiveRecord::Base.connection, table_name).first.fixtures[fixture_symbol.to_s]
I have already updated the wiki at https://github.com/cucumber/cucumber/wiki/Fixtures
I've got a situation where I need to validate some regular expressions.
So, during my application run, I may want to test that a particular regex:
Contains no spaces
Contains only a certain number of capture groups
Does not use certain characters
Only contains a certain number of wildcards
rspec seems like the perfect tool for doing this. I realize that it's typically used to test application interfaces, assumptions and logic before an application is run, however. But, the natural syntax combined with the automatic reporting output would be nice to have.
Questions:
Is this an appropriate use of rspec?
How can one call a description from within a running application?
Or, should I abandon this approach and simply write methods within my class to perform the validations?
Using rspec in this way is highly discouraged and unusual. You should leave testing code in a :test group in your Gemfile and not reference it in your app.
Instead, use rails validations that your field matches a regex format, and then write tests in rspec to verify your validations.
This is definitely something new: using rspec inside rails for validation. But for specific problems one tends to propose to use a DSL, and as such rspec is a DSL which might just perfectly suited for your job.
So if that is the case: why not, yes, go ahead. Be creative and find new ways to use the tools you have.
Just a small warning: from the few points you marked, the complexity does not seem to be too big, so make sure you are not using a bazooka to kill a fly. Rspec is a big and very powerful tool, tying in rspec to run during the rails process might not be entirely straightforward.
If you want to generate a report, you could use the global after(:all) { puts "report goes here" } or after(:each). If you expect some of your data to blow up your tests, you can test for .should raise_exception. I imagine you'd be writing lots of exception handling to keep the expected failures out of the output. Logging the results to a database or a file might also be annoying. If you can, describe the test that you are doing on the data and then just parse the output of rspec at the end.
class Car
attr_accessor :doors
end
describe "Car" do
it "should have doors" do
Car.new.should respond_to(:doors)
fail("failing intentionally")
end
it "should pass this easily" do
Car.new should_not be nil
end
after(:all) { puts "report here" }
end
You can see below that I have a description of the test that failed.
$ rspec rspec_fail.rb
F.report here
Failures:
1) Car should have doors
Failure/Error: fail("failing intentionally")
RuntimeError:
failing intentionally
# ./rspec_fail.rb:9:in `block (2 levels) in <top (required)>'
Finished in 0.00052 seconds
2 examples, 1 failure
I would be easy enough to just make a report of the failures if this was testing text and regex's. Failure/Error: fail("Data has spaces") etc.
This seems like a simple question but I can't find the answer anywhere. I've noticed that in general, tests in a Ruby on Rails app can be written as:
test "the truth" do
assert true
end
or
def the_truth
assert true
end
It seems newer material writes tests the first way, but I can't seem to find a reason for this. Is one favored over the other? Is one more correct? Thanks.
There has been a shift in recent years from short, abbreviated test names to longer, sentence-like test names. This is partly due to the popularity of RSpec and the concept that tests are specs and should be descriptive.
If you prefer descriptive test names, I highly recommend going with the test method. I find it to be more readable.
test "should not be able to login with invalid password" do
#...
end
def_should_not_be_able_to_login_with_invalid_password
#...
end
Also, because the description is a string it can contain any characters. With def you are limited in which characters you can use.
I believe the first method was implemented starting with Rails 2.2.
As far as I am aware, it simply improves readability of your code (as def can be any function while test is used only in test cases).
Good luck!
As Mike Trpcic suggests you should check out RSpec and Cucumber. I'd like to add that you should also take a look at:
Shoulda (http://github.com/thoughtbot/shoulda/tree/master)
Factory Girl (http://github.com/thoughtbot/factory_girl/tree/master)
Shoulda is a macro framework for writing concise unit tests for your models/controllers, while the second is a replacement for fixtures.
I would suggest doing your testing with either RSpec or Cucumber. I use both to test all my applications. RSpec is used to test the models and controllers, and Cucumber tests the Views (via the included Webrat functionality).