Running multiple Rspec files in parallel with Selenium Grid - testing

I have been working on a Rspec/Selenium Webdriver test framework where I need to run my Rspec tests distributed across multiple files in same directory spec/*_test.rb.I was looking for the existing solutions available and stumbled upon deep test gem (https://github.com/qxjit/deep-test) which helps driving the tests in parallel leveraging selenium grid but I was not able to implement it based on the documentation available and looks like there is no active development going on with it.Are there any ported version of deep test available to work with RSpec > 2.0.
I also looked into parallel_tests (https://github.com/grosser/parallel_tests) but not sure how we can use it for running multiple process on the same cpu with each process running a different rSpec test.
Here is a snippet from one of my spec file,
require 'selenium-webdriver'
require File.join(File.dirname(__FILE__),'../support/Setup')
require 'rspec'
require File.join(File.dirname(__FILE__),'../support/spec_helper')
require File.join(File.dirname(__FILE__),'../support/Helper')
describe "Test", :type => :selenium do
it "should search for flights" do
airline.home_page.queryFlight('oneWay', 'ATL', 'ORD', 'today')
end
it "should list all the flight results and select one flight" do
airline.flight_list_page.selectFlight
end
end
Similarly i have other spec files which I am trying to run in parallel.

Related

New browser opens for every feature being executed - WATIR

We are using the Selenium Cucumber framework with Watir.
We have split one scenario into different features and all these features needs to run on one browser to complete the scenario.
Currently 1 feature completes and then the browser is closed and then a new instance of Firefox is opened; not preserving the state of the previous instance.
For our tests to run effectively, we need these features to be completed on the same browser instance.
How do we prevent a new browser instance open after each feature has been executed?
Here is our test structure:
W2.1.1-Set_Project_Information.feature
W2.1.2-Select_Shotlist.feature
W2.1.3-Flag_shotlist_requiring_physical_inspection.feature
W2.1.4-Select_applicable_shotlist_task.feature
W2.1.5-Record_Primary_Applicant.feature
My env.rb:
require 'rubygems'
require 'watir'
require 'selenium-webdriver'
require 'rspec'
browser = Watir::Browser.new :firefox
Before do
#browser = Watir::Browser.new :chrome
#browser = browser
#browser.goto "https://test.branzartisan.com"
#browser.window.maximize
sleep(5)
puts "###Browser Invoke###"
end
After do |scenario|
#browser.cookies.clear
#browser.refresh
end
The answer is the same as here: https://stackoverflow.com/a/17624188/4072371
That being said, I feel obligated to point out that ideally you can make your tests independent of each other.
The solution to this issue was removing the before do block from the env.rb file.
This prevented the invoking of a new Firefox instance before each scenario.

Locking the version of PhantomJS that Poltergeist uses

I have a Ruby on Rails app that runs feature tests using Capybara, Poltergeist and PhantomJS.
Version 2.0.0 of PhantomJS has a rather significant bug that breaks a lot of tests (https://github.com/ariya/phantomjs/issues/12506) so I'd like to force the app to use a different version of PhantomJS when running the tests.
Is this possible from within Poltergeist's configuration, to raise an error or a warning if this buggy version is used, or is my best bet simply putting a note in the app's readme saying 'don't use version 2.0.0 due to this bug'?
at the moment my Capybara/Poltergeist configuration is very basic:
Capybara.register_driver :poltergeist do |app|
Capybara::Poltergeist::Driver.new(app, :timeout => 90)
end
As #pguardiario commented, you can just do something like
if `phantomjs -v`.start_with? '2'
#output whatever kind of warning you want
end
however the Poltergeist master branch has a fix for that particular issue so you could just try using that instead

RSpec View testing with Rails3 and RSpec2

RSpec2 does not include an have_tag test helper. Using webrat's have_tag or have_selector matchers instead is not possible because Webrat and Rails 3 are not compatible yet. Is there a way to write useful RSpec view tests? It is possible to use assert_select instead of have_tag, but then one could Test::Unit tests in the first place. Or is it no longer recommendable to write RSpec view tests, because integration tests with Capybara or Cucumber are better?
Actually, Webrat works with Rails 3. I have tested this and I was able to use the have_selector matcher (have_tag didn't work).
You can take a look at this Google group discussion. Basically, you don't need the Webrat.configure block mentioned in the webrat readme, and following the mailing list solution, add these lines in your spec_helper.rb:
include Webrat::Methods
include Webrat::Matchers
As you can see, Webrat is not so updated anymore, so yes, you might be better off with integration testing with Cucumber (+ Capybara).
Webrat caused too much trouble, it is also possible to use Capybara with RSpec. The Capybara DSL (with the functions has_selector?, has_content?, etc.) is available for the following RSpec tests: spec/requests, spec/acceptance, or spec/integration.
If you use the latest version of Capybara (~> 1.0.1) - older versions like 0.4.0 won't support this - and add the following lines to your spec_helper.rb file
require "capybara/rspec"
require "capybara/rails"
then you could write for example the following RSpec request test
require 'spec_helper'
describe "Posts" do
describe "GET /blog" do
it "should get blog posts" do
get blog_path
response.status.should be(200)
response.body.should have_selector "div#blog_header"
response.body.should have_selector "div#blog_posts"
end
end
end

Set up RSpec to test a gem (not Rails)

It is pretty easy with the added generator of rspec-rails to set up RSpec for testing a Rails application. But how about adding RSpec for testing a gem in development?
I am not using jeweler or such tools. I just used Bundler (bundle gem my_gem) to setup the structure for the new gem and edit the *.gemspec manually.
I also added s.add_development_dependency "rspec", ">= 2.0.0" to gemspec and did a bundle install.
Is there some nice tutorial what to do next to get RSpec working?
I've updated this answer to match current best practices:
Bundler supports gem development perfectly. If you are creating a gem, the only thing you need to have in your Gemfile is the following:
source "https://rubygems.org"
gemspec
This tells Bundler to look inside your gemspec file for the dependencies when you run bundle install.
Next up, make sure that RSpec is a development dependency of your gem. Edit the gemspec so it reads:
spec.add_development_dependency "rspec"
Next, create spec/spec_helper.rb and add something like:
require 'bundler/setup'
Bundler.setup
require 'your_gem_name' # and any other gems you need
RSpec.configure do |config|
# some (optional) config here
end
The first two lines tell Bundler to load only the gems inside your gemspec. When you install your own gem on your own machine, this will force your specs to use your current code, not the version you have installed separately.
Create a spec, for example spec/foobar_spec.rb:
require 'spec_helper'
describe Foobar do
pending "write it"
end
Optional: add a .rspec file for default options and put it in your gem's root path:
--color
--format documentation
Finally: run the specs:
$ rspec spec/foobar_spec.rb
Iain's solution above works great!
If you also want a Rakefile, this is all you need:
require 'rspec/core/rake_task'
RSpec::Core::RakeTask.new(:spec)
# If you want to make this the default task
task default: :spec
Check the RDoc for RakeTask for various options that you can optionally pass into the task definition.
You can generate your new gem with rspec by running bundler gem --test=rspec my_gem. No additional Setup!
I always forget this. It's implemented here: https://github.com/bundler/bundler/blob/33d2f67d56fe8bf00b0189c26125d27527ef1516/lib/bundler/cli/gem.rb#L36
Here's a cheap and easy (though not officially recommended) way:
Make a dir in your gem's root called spec, put your specs in there. You probably already have rspec installed, but if you don't, just do a gem install rspec and forget Gemfiles and bundler.
Next, you'll make a spec, and you need to tell it where your app is, where your files are, and include the file you want to test (along with any dependencies it has):
# spec/awesome_gem/awesome.rb
APP_ROOT = File.expand_path(File.join(File.dirname(__FILE__), '..', '..'))
$: << File.join(APP_ROOT, 'lib/awesome_gem') # so rspec knows where your file could be
require 'some_file_in_the_above_dir' # this loads the class you want to test
describe AwesomeGem::Awesome do
before do
#dog = AwesomeGem::Awesome.new(name: 'woofer!')
end
it 'should have a name' do
#dog.name.should eq 'woofer!'
end
context '#lick_things' do
it 'should return the dog\'s name in a string' do
#dog.lick_things.should include 'woofer!:'
end
end
end
Open up Terminal and run rspec:
~/awesome_gem $ rspec
..
Finished in 0.56 seconds
2 examples, 0 failures
If you want some .rspec options love, go make a .rspec file and put it in your gem's root path. Mine looks like this:
# .rspec
--format documentation --color --debug --fail-fast
Easy, fast, neat!
I like this because you don't have to add any dependencies to your project at all, and the whole thing remains very fast. bundle exec slows things down a little, which is what you'd have to do to make sure you're using the same version of rspec all the time. That 0.56 seconds it took to run two tests was 99% taken up by the time it took my computer to load up rspec. Running hundreds of specs should be extremely fast. The only issue you could run into that I'm aware of is if you change versions of rspec and the new version isn't backwards compatible with some function you used in your test, you might have to re-write some tests.
This is nice if you are doing one-off specs or have some good reason to NOT include rspec in your gemspec, however it's not very good for enabling sharing or enforcing compatibility.

Get Cucumber to use the test environment in Sinatra

This seems right, but doesn't seem to work.
env.rb:
class MyWorld
set :environment, :test
end
app.rb:
configure :development do
DataMapper::setup(:default, "sqlite3://development.sqlite3")
end
configure :test do
DataMapper::setup(:default, "sqlite3://test.sqlite3")
end
It keeps using the development environment. Am I missing something, or am I doing it wrong?
Put this at the top of env.rb, and things work perfectly:
env.rb
ENV['RACK_ENV'] = 'test'
Alternatively, this will do the same without having to edit any files:
$ RACK_ENV=test cucumber features
You might want to look into the cucumber-sinatra gem. It has options to autogenerate a minimal amount of code (including your Sinatra app & rackup file). It should provide the correct syntax for getting cucumber scripts to run in test configuration.