I noticed in the Introduction at 4:50, the graphic indicates that with Outside-in Development, the outside is handled with Cucumber, yet we didn’t use Cucumber in the workshop. Would Cucumber have been overkill in the example applications or does Capybara replace Cucumber?
Can you describe the testing stack used at Thoughtbot? As a new rails developer, I’m trying to understand what’s inherently wrong with the native Rails test suite. Most TDD learning resources focus on RSpec in combination with other components.
It seems that there is some overlap in the available testing gems. Does anybody know of a good, current resource, that describes all of the options?
You can write cucumber style integration tests in Rspec. We’re actually considering doing this and moving away from Rspec + Cucumber and keeping the different types of tests in separate folders. Has anyone done this and regretted it? Are there any disadvantages to this?
@Noah_Clark is exactly right in that you can write capybara style specs using the rspec suite and that is the process we’ve moved to at thoughtbot. We follow the same ideal of testing but we’ve removed the extra layer of cucumber that we didn’t find much value in. That would be why @Chris_Bradley we did not cover Cucumber in your workshop. That was something we had done in the past and have since changed how we operate.
As for an overall view of how we test at thoughtbot, our process is usually focused around using rpsec. We would follow the same process that we use in our workshops. We start by writing a high level integration test and as we hit places in our classes that we are adding functionality, we spec those out using rspec unit tests. That is a very short overview mainly because the process can definitely change from situation to situation.
As for what is ‘wrong’ with the native test suite that ships with Rails, I don’t think there is anything wrong. We’ve found that rspec has a lot of benefits for making our tests easier to write, understand and maintain. It allows us to be more descriptive in our tests and allows us to explain why something is happening rather than explaining exactly how something happens.
I would recommend trying out MiniTest and seeing how it feels to you. I love rspec but that doesn’t mean I hold a grudge against MiniTest and I think it is a great framework.
@Noah_Clark we put our integration tests typically in a spec/features directory. How they are organized below that tends to vary from project to project. I’ve seen `spec/features/user and spec/features/admin’ before but I I have also seen it organized by category or what the tests are dealing with. On the whole, I’ve not heard of anyone from thoughtbot who has regretted the move to rspec. We usually write our rspec tests in a very descriptive way almost in the same language we would have used with cucumber, we simply omit the extra translation!
@drapergeek, Does this imply that Thoughtbot is moving away from Capybara?
I’ve attempted this by written two integration tests, testing identical functionality, but the first uses RSpec syntax and the Second uses Capybara:
require 'spec_helper'
describe "SignupEmails" do
it "emails user when they sign up" do
user = FactoryGirl.build(:user)
visit root_path
click_link "Sign Up"
...
expect(last_email.to).to include(user.email)
end
end
and
require 'spec_helper.rb'
feature 'sign up new user' do
scenario 'User receives confirmation email' do
user = FactoryGirl.build(:user)
visit root_path
click_link "Sign Up"
...
expect(last_email.to).to include(user.email)
end
end
Is the difference just perceived readability? The RSpec version consistently runs about 2x faster. Does Capybara provide advantages that my test examples don’t leverage?
I apologize @Chris_Bradley, that was a poorly written sentence. It should be ‘You can write cucumber style specs using the rspec suite and capybara. That is the process we have moved to’. We are definitely not abandoning capybara, only cucumber!
As for the difference between your specs, yes, the only difference between those is the readability. The second version is still using capybara for the visit and click_link methods, you are only using different block method names. feature is simply an alias for describe and scenario is an alias for it.
The two examples should be running the same speed and I’m not sure how either is difference in time speeds. The only thing I could guess is that you have different spec_helpers that are loading different information (hence the difference in spec_helper and spec_helper.rb).
From my experience (currently at a company with several large, integrated projects and vast Cucumber tests,) the Rspec/Capy only approach is far more sustainable in my opinion. The problem I’ve started to have with Cucumber is that you’re effectively maintaining 2 separate files per test – the step definitions and the actual Cukes. For me, this makes my workflow much slower than just having Rspec-only.
Your mileage may vary, but I certainly lean away from Cucumber whenever possible.