I use RSpec to test my lovely little web app. For integration tests I use Steak. When using Rails generators (yep, I know that this is not the Zen way of doing TDD) there are also some files in spec/requests generated. As stated on link text it is something similiar to integration test (but I couldn't find much more info).
Are those request specs still recommended when using something like Steak and Cucumber?
It all depends on what you need and want. The goal of testing is to prove that your app works once, not twice or more times.
I personally write rspec tests for models and helpers. I use cucumber to test that my views and controllers are working the way I expect them to. With this I can prove that my entire app works as I expect it to, so no, I don't use spec/requests.
Occasionally I do use spec/requests to test APIs, but you can do that with cucumber as well.
Some don't like the BDD-way cucumber works and stick with spec/requests. In the end it's all a matter of taste.
Related
A contractor for our startup installed the Selenium-based Nightwatch testing framework, since our stack is React-heavy. But he told me that it could even be used to test our Rails code. A new contractor said, to the contrary, that Nightwatch couldn't do unit tests of our Rails controllers and models (which makes sense to me).
Who is right? Do you suppose the first programmer had in mind just that we would do end-to-end testing (certain inputs lead to certain outputs), and that we need not test the details of the Rails code? Do we, as I suspect and as the new contractor asserts, need RSpec or some other Ruby-based testing framework to handle our Rails code, if we want to be a TDD shop?
Yes it can be used to test Rails. But only from the outside (only through the Browser). So no Unit/Controller/View Tests.
You'll need MiniTest or Rspec for those.
My two cents (also see comment by #SteveCarey): Since I prefer to stick with what comes with Rails and use as little external tools as possible:
Have a look at System Tests that have been introduced with Rails 5.1 or, if you are on a older version, see if you can write those tests using Capybara/Integration Tests.
Update:
You can find more details on testing framework here: http://guides.rubyonrails.org/v4.1/testing.html#brief-note-about-minitest
It was Test::Unit and nowadays is Minitest. But the basics are the same so it does not really matter.
Another popular testing framework is RSpec. Which you can use instead of Minitest/TestUnit if you want to. I prefer Minitest but there are pros and cons for both frameworks.
Rails 4.2 came with Unit-tests, Functional/Controller-tests and Integration-tests. The built in thing that resembles Nightwatch the most are Integration-tests: http://guides.rubyonrails.org/v4.1/testing.html#integration-testing
You can also look at libraries such as Capybara (https://github.com/teamcapybara/capybara) which calls itself an Acceptance Test framework. It integrates nicely with TestUnit/Minitest/Rspec.
I have just finished reading many different web pages on the subject of Cucumber. It appears to be impossible to use Cucumber to test an existing Ruby on Rails application. I'm just asking in case I missed something. (We are considering using it for future RoR app development.)
While I am asking, what is the current consensus on the best tool to test an existing Ruby on Rails application?
I did a little exploration with WATIR and it seems easy to use, but driving the web browser results in being not scalable. I have read some have moved from WATIR to Celerity....
However, I am in an environment where we are starting from zero previous testing. What is the 'best' choice to quickly write tests for an existing Ruby on Rails application?
In no way is Cucumber unable to test an existing application. Not sure what gave you this idea, but perhaps because it's typically used with test-driven development?
Cucumber is by far the most widely used integration testing software for Rails. I would definitely suggest using Cucumber with Capybara, Guard, Spork, and RSpec for your testing suite. (RSpec for unit testing, Capybara for integration tests, Guard and Spork for running your tests quickly).
If you've never looked at Cucumber before, you might want to take a look at some tutorials first.
To get started on your project, try to make a Cucumber feature for a simple feature. For example, write a test to visit the homepage. Something like:
Feature: View homepage
Given I am on the profile page
When I click "home"
Then I should see the homepage logo
Once you've understood that, move on to more complicated features. Examples might include create a user account, login, view a profile, etc. (I don't know what your application does but I think you get the point.)
Cucumber is able to test an existing application.
You have to set configuration setting for cucumber and generate cucumber folder by rails g cucumber
before run this command you have to include gem: gem 'cucumber'.
I have a Rails 2.3.5 app which is serving a card game. I've been a bit lax in writing tests for it (read: I haven't written any :embarrassed:), and I'd like to make a start now.
From reading other questions, I think I probably want to be using Shoulda extending Test::Unit for unit testing.
I wondered about using Capybara extending RSpec for functional testing, but the majority of users' interaction with the app is via POST, which I understand Capybara doesn't handle.
Since this is a card game, I obviously need the ability to control rand; I also definitely need the framework to handle Javascript.
Is Test::Unit + Shoulda suitable?
Am I correct that Capybara can't handle POST? Can I work around that?
Is there a better option instead of Capybara?
Can these methods handle the randomness involved in a card-game? Presumably, for Test::Unit at least, I can just call srand at some early stage to fix the generator, but I don't know if that's doable for Capybara/RSpec/anything else.
Can anyone point me to resources dealing specifically with setting up Shoulda, Capybara and RSpec for Rails 2.3.5? It's a little hard to tell what's Rails 3 specific and what isn't.
Would I gain anything from adding Watir / Firewatir into the mix?
I realise the above questions are manifold, but they basically boil down to "does this work, or have you any better suggestions?"
If the majority of the users' interactions are via POST, is it via an API (as opposed to filling out forms or something)?
Just about any combination of RSpec/Shoulda/Capybara/Test Unit/Rack::Test could work for you depending on your need. They're all capable. However, these are my recommendations:
If you've decided you want integration testing via HTML pages, use Cucumber and Capybara
If you've decided you want integration testing via HTTP API, use RSpec and Rack::Test
You probably want to fake out randomness.
You probably don't need Watir/Firewatir.
It does look like you can make POST requests via some Capybara drivers:
http://suffix.be/blog/capybara-post-requests
When Rails moved to 3.0, RSpec went to 2.0 so for at least RSpec, you'd want RSpec and RSpec Rails 1.3.2.
By "fake out randomess", I mean redefine srand in your tests so you can predictably run them.
module Kernel
def rand
YourApp.rand
end
end
module MyApp
class << self
attr_accessor :rand
end
end
Then, before you have the user press the button, run a step definition like "When random returns 6", which will set MyApp.rand = 6.
I have few integration tests in Capybara+RSpec for a Rails project. Today I encountered Steak gem that meant to be pure Ruby alternative to Cucumber. Though at first glance I don't see any value in either of them. For me it looks like Steak renames describe to feature and it to scenario. Personally i would prefer describe and it because i got used to them and i don't see any reason to make my acceptance tests to look different from my controller or model tests.
Am I missing something?
Steak is RSpec+Capybara. Steak is also these three other things: the name for this Acceptance BDD approach (so that people knows how you test just but using that name), a gem that makes that approach as convenient as possible (so that you don't have to create the same directories and helpers for each project) and a community of developers using it (so that if you have problems, you know where to ask).
For additional rationale, you may want to check out the "Why Steak?" section in the project's README, or this other StackOverflow awswer.
I just get started using BDD in Rails application, but I'm not sure what are best practices and workflows? And what other things that I really need for testing for my project such as step definitions, controllers, models, and views? Do I need to test all of those?
I generally think of Cucumber as a way to do integration testing on your application. Combined with Webrat, you can test user workflows, views and so on in a great way. For unit tests, you'll want to go down to a lower level and test your models just with rspec. You may also want to do some functional tests on the controllers, and I probably wouldn't use Cucumber for that either.
Here are a couple of videos:
http://confreaks.com/videos/72-mwrc2009-bdd-with-cucumber
http://rubyconf2008.confreaks.com/rspec-and-cucumber.html
Ryan Bates has some good Railscasts on these topics:
Beginning with Cucumber
Webrat
More on Cucumber
This may be a matter of taste, but having tried out Rspec I prefer using the built-in Rails testing framework along with a gem called Shoulda. In my opinion, that combination lets you write much clearer, more succinct and understandable tests than Rspec by far. But not everyone would agree.
Shoulda's contexts let you organize your tests into logical hierarchies which really helps when you're trying to test all the possible paths some crazy, branching situation, like user logs in with right pw, wrong pw, right pw but registration not confirmed, etc.
In addition be sure to install the ZenTest gem. That lets you just execute the command $ autotest and your tests will run automatically every time you change a file.