When I run the JS feature tests in isolation they work fine.
When I run the test suite, then they fail.
I execute '--bisect' with 'rspec spec' and return 1 test that produce the fail.
spec:
https://gist.github.com/lfgdz/c56481ce88cdb80750fa6d98f0ec1a4d
spec_helper:
https://gist.github.com/lfgdz/08b1b82d2a36aaf7929af79b04c652c1
When specs pass in isolation but fail when run together, there must be some interdependency or information that's leaking between them.
As #slowjack2k said, your spec_helper.rb specifies:
config.use_transactional_fixtures = false
Per the RSpec Transactions doc, that means you've asked RSpec not to wrap each spec in a transaction. This means changes to the database made during one spec can impact others, including between standard unit tests and Capybara feature tests.
If you really need transaction fixtures turned off, you'll need to use database_cleaner or some other mechanism to ensure that changes made in one spec don't interfere with other specs.
Related
Is there a difference between a feature spec and system spec? Both seem to use Capybara to test the full application yet they have different docs on RSpec.
System specs are built on top of Rails own system tests while feature specs were implemented by RSpec before Rails had system tests. If you're starting a new project write system specs, but if you have existing feature specs there's really nothing to be gained currently by changing them to system specs since functionality wise they're basically identical.
I want to write acceptance testing through cucumber and capybara. i have experience with rspec. I want to write integration/features test cases . I want outcome to be seen on a web browser which shows the test case running. what are the gems required for writing test cases .
If you are already familiar with RSpec, I recommend you to use RSpec with Capybara for acceptance testing. RSpec is testing framework, and Capybara is a library that helps you to test web applications by simulating how a real user would interact with your app.
Acceptance tests in RSpec with Capybara are called "feature specs" and live in /spec/features directory in Rails. Capybara comes with a built in DSL for writing descriptive acceptance tests with RSpec (feature/scenario), but you may also use traditional RSpec DSL (describe/it).
Capybara supports several drivers, and its default driver RackTest doesn't support JavaScript. So, probably, you'll want to use one of the alternative drivers (I prefer Poltergeist, but it is headless, so if you want to see result in the browser, you may use Selenium driver). In this case, you'll need to set up database_cleaner to clear your database between tests. Capybara's README contains a lot of information about its configuration and usage with RSpec, configuring driver and using database_cleaner.
You can start with this and this screencasts. But remember, that they are a little bit outdated and use traditional RSpec DSL (instead of new Capybara DSL), and use old convention, when "feature" specs were called "request" specs. Currently, by convention, "request" specs, are integration tests without capybara. So you'll need to create your capybara specs in spec/features directory, not spec/requests. And if you want to use Capybara DSL, this is easy to fix too. Just replace describe with feature, it with scenario, let with given etc. It is well documented in Capybara's README.
Hope this helps.
I'm having trouble with PaperTrail (auto-versioning of objects for Rails) being used with RSpec tests. Normally I want my tests to run without PaperTrail versioning, but there are a handful of tests for which I want PaperTrail turned on. I typically run my tests with Guard and Spork, and I can use things like PaperTrail.enabled = true and PaperTrail.enabled = false around a given test and everything works fine.
However, when I run the tests with RSpec, the tests requiring PaperTrail fail. To be more specific, it appears that while code in before filters can produce versions objects, code in the tests cannot. After a considerable amount of digging and tinkering and trying code snippets (I've tried this and this), it looks like the best solution is to use the require "paper_trail/frameworks/rspec" line mentioned in the PaperTrail README.
Unfortunately, each of these keeps me right where I started—tests pass with Guard/Spork but not vanilla RSpec. This is in particular an issue because while I use Spork locally, our continous integration server runs RSpec directly.
Does anyone have any insight?
PaperTrail now has documentation on tests with vanilla rspec
https://github.com/paper-trail-gem/paper_trail#7b-rspec
After including require 'paper_trail/frameworks/rspec' in your spec/rails_helpers.rb
... PaperTrail will be turned off for all tests by default. To enable PaperTrail for a test you can either wrap the test in a with_versioning block, or pass in versioning: true option to a spec block.
Somehow my issue was fixed by changing before(:all) and after(:all) behavior to before(:each) and after(:each).
I have the following mocha mock that works great.
In a test.rb file:
setup do
Date.stubs(:today).returns(Date.new(2011, 7, 19))
Time.stubs(:now).returns(Time.new(2011,1,1,9,0))
end
The problem is that the timing is broken for the tests. After the tests run the date and time objects are still mocked.(!)
Finished in -21949774.01594216 seconds.
I added the following:
teardown do
Date.unstubs(:today)
Time.unstubs(:now)
end
This throws the following error for each test: WARNING: there is already a transaction in progress
Is this the proper way to unstub? Is it better to unstub at the end of the test file or even at the end of unit test suite?
Working in Rails 3.07 and Mocha 0.9.12
Thanks.
I don't know if this is fully your problem, but it is just unstub, not pluralized.
Other than that, there should be no issue. You definitely want to unstub after each test (or set of tests, if a bunch of tests need the stubbing) because once stubbed, it will stay stubbed, and that can screw up other tests.
The accepted answer is spreading misinformation and should be considered harmful.
One of the main purposes of a mocking library like Mocha is to provide automatic mock/stub teardown as part of the integration to various testing libraries. In fact if you look at the GitHub repo for Mocha you will see that significant maintenance effort is put into making Mocha work smoothly with all the versions of several different testing frameworks.
If this isn't working properly then you need to figure out why Mocha's built-in teardown isn't working. Unstubbing manually in your own teardown is just papering over the problem, and could hide subtler issues with stub leakage or Mocha otherwise misbehaving.
If I had to take a wild guess money would be on your stub somehow being run outside of an actual test because that's the most common cause I've seen for this kind of thing in the wild, but there's not enough information from the question to really ascertain.
right now I use rspec for my tests. to run rspec all I have to do is:
rake spec
I now want to use Cucumber to write tests for making sure the paths for sign in and sign up work correctly with Devise & Omniauth.
To use Cucumber I need to write tests in /features right?
So does that mean to test I need to run
rake spec
And then run another command
cucumber
So now I have to run two testing frameworks?
Thanks
Adapted from http://blog.andywaite.com/2013/02/28/rakefile-cucumber-rspec-jasmine/
Rakefile:
require 'rspec/core/rake_task'
require 'cucumber/rake/task'
RSpec::Core::RakeTask.new
Cucumber::Rake::Task.new
task :default => [:spec, :cucumber]
But I prefer guard to automatically run tests.
Yes. One is a unit testing framework, the other is for high level acceptance tests.
Also, if you are looking for integration tests rather then acceptance tests (which is what it sounds like), plain capybara with rspec will probably be a better fit (https://github.com/jnicklas/capybara, scroll down to capybara + rspec)
Yes that's correct. Generally speaking I use Rspec for unit testing, and cucumber for integration. If you find RSpec is covering integration tests for you, and you dont need to write cucumber features to spec out the app with a client or systems analyst, then perhaps cucumber is not for you. Personally, i love how cucumber works for integration testing. It feels very reusable, and it's easy to understand what's going on in a test.
To address your specificity about running 2 commands, running autotest to automatically run your tests whenever you make a change to the spec code or program code removes the need to use the rake commands.
https://github.com/dchelimsky/rspec/wiki/Autotest-Integration
If you use cucumber the running AUTOFEATURE=true autotest will run rspec tests and cucumber specs in sequence
https://github.com/cucumber/cucumber/wiki/Autotest-Integration
Autotest has a great function in that it runs the whole spec suite but, if any tests fail it will rerun only that test until it passes, and then reruns the entire test again. It also has the added value of randomizing the order of tests so that it ensures the tests are valid in isolation