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.
Related
In rails configuring guides, https://edgeguides.rubyonrails.org/configuring.html#configuring-rails-components, under section 3.3, there are a list of methods that can be used in config generators block. Among them are system_tests and test_framework, which are defined as follows:
system_tests defines which integration tool to use to generate system
tests. Defaults to :test_unit
test_framework defines which test framework to use. Defaults to false
and will use minitest by default.
The question is what's the difference between them, cause integration tool and test framework are both synonyms for me. Besides test_unit and minitest, based in my researchs on Google, are both test frameworks, and minitest is kind of a test_unit replacement.
You migth also have noted that in test_framework definition is written: "Defaults to false and will use minitest by default". The only left question is, what?!!!
If it defaults to false, shouldn't it mean that no test framework will be used? This assertion is completely illogical.
I agree, it is confusing how they write it.
I think when they say "system test," they are referring to the popular "integration tests" or "feature tests" which as you know, interacts with the browser. So they're saying they will use test unit which will probably use capybara driver under the hood.
I think when they say "test framework," they are saying you could use something like rspec to write your tests instead of minitest.
It will probably help if you think of integration tool as the under-the-hood driver such as capybara.
Sorry I'm on mobile app and cannot see rest of your question so I will submit then update if needed.
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 have a good understanding of the differences between unit and intergration tests in RoR in theory. I'm using rspec and capybara to do a lot of testing on my site. What I don't understand is how do you run different tests? If I do
bundle exec rspec
it will run all of my specs in all of my spec folders (model, controller, views, integration, etc). If I want to run an integration test, is it as simple as ?
bundle exec rspec spec/integration
I know there are some differences between these types of test behind the scenes. Specifically this problem (which I also have) has me thinking about unit vs. integration: How to test for a redirect with Rspec and Capybara
What does Rails do differently when running integration tests? The solution posted in the above problem is
Checking for redirect is not supported in rspec-rails request specs,
but is supported in Rails integration tests.
So how do I make one of my tests an integration test? Is it just a matter of putting it in the right spec folder?
As I understand it rspec is designed specifically for unit testing purposes, thus you'll need to use something else for integration testing. The message seems it imply that Rails can do integration tests as well. I don't have any experience or knowledge of testing in rails alone, but I do know of the cucumber gem that is built very well for integration tests.
It has it's own domain specific language and other quirks you'll need to get used to but it should have the capability you're looking for.
I find that in order to thoroughly test a Rails application with Rspec I am required to write more test code than actual functional Ruby code. Call me crazy but this does not seems right. Is there a different/alternate approach (even one that is not as comprehensive as Rspec).
For unit testing I guess you won't find any replacement.
But for integration testing, you could create scenarios within your browser thanks to Selenium. See: http://seleniumhq.org/
There are many option available here are the few list
Rspec
Watir
Cucumber
factorygirl
capybara
and many more
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