I have read Rspec from RubyonRails Tutorial 3 book. But i am actually not getting the language what it is trying to explain.Please can anyone explain me in simple way for easy understanding of it.
At its core, RSpec is just a ruby library for automated testing, just like Test::Unit or Minitest. The thing with RSpec is that it uses very special syntax and method names to make the test code read like english prose. This is done to give the reader a better understanding of the test code and make it easier to read, although whether RSpec achieves this is controversial and highly subjective.
If you're still having trouble understanding RSpec, I recommend this tutorial. It teaches RSpec as part of regular Ruby on Rails development.
What I understand so far is that RSpec (and test-driven development in general) is a method of developing programs while ensuring that the program does what you want it to do. The process is three-part:
Write a test to test for a new feature. The test will fail because you haven't written the code yet.
Write the code for the new feature.
Run the test and modify the code until the test passes.
Related
When developing a project, I turned to shoulda for testing just because it's what I was familiar with. However, the project hasn't had a release in over a year. I'm wondering if anyone has recommendations on alternatives, or if I should just stick with shoulda?
The remarkable gem is the closest I've found to Shoulda. Unfortunately it looks like it hasn't been updated in even longer. It also relies on RSpec and it not compatible with Test::Unit.
It isn't clear to me how well it supports Rails 3 - although there are some instructions for getting it up and running.
After looking into both Shoulda and Remarkable I decided to go with Shoulda as it still seemed the more likely set of helpers to be updated.
One of the issues you will have with shoulda is that Thoughtbot uses RSpec rather than Test::Unit, which is part of the reason that the Shoulda gem (which exists for the benefit of Test::Unit users) has seen little activity - the RSpec component of the gem, shoulda-matchers, has been updated much more recently. Thoughtbot also found a new maintainer for shoulda-contextin Jan 2012 (this is the gem required alongside shoulda-matchers to get everything working in Test::Unit - the shoulda gem really only pulls in shoulda-matchers and shoulda-context) so there should be more focus on the Test::Unit side moving forward I expect.
Hopefully these moves give at least a little confidence that Shoulda for Test::Unit will be updated more frequently moving forward. In the absence of any other suggestions I would stick with Shoulda for the time being.
Rspec is the most common BDD framework used for testing in ruby and is quite popular. It works well with shoulda assertions in case u like some of the assertions in shoulda. Ruby also ships by default with test/unit for testing.
Between, what are the issues you have with shoulda at the moment?
I've been meaning to get into testing. After reading about a few testing frameworks (test::unit, Rspec, etc). I've decided give Rspec and Capybara a try.
I'd like to understand how experienced developers utilize these libraries properly. Which in-turn will help me write better application code and find bugs or little errors in the smallest cracks in the application.
Approaching this as a total TDD nooby. What online sources have you come across to help you learn about Rspec + Capybara. I found this Railscast, which is a good starting point. Are there any other sources / articles I should be reading?
I came across The Rspec Book, which is great for Rspec, but touches more on Cucumber examples.
In addition, how can I find out all the functions available for Capybara. i.e. fill_in, click_link, etc. The Github page mentions a few, but not all.
I also use Rspec with Capybara, and i get along very well with this references:
Action methods: http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Actions
Find methods: http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Finders
Match methods: http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Matchers
Hope it helps!
If you were just starting out in rails which path would you encourage new users to go down with regards to Testing.
Anything I read about regarding Rails 3, tells me I should be using Rspec 2. But Rspec comes with a whole whack of other things I need to learn like
gem 'capybara'
gem 'database_cleaner'
gem 'cucumber-rails'
gem 'cucumber'
gem 'spork'
gem 'launchy'
And then one of my friends just told me that I should just stick to the testing framework that comes with rails, and maybe just integrate 'shoulda' into the test process because it has a nice syntax.
When it comes to testing it seems like we have way too many options and too many ways of doing something. Maybe this is a good thing, but I always thought rails was about creating common conventions and avoiding doing the same thing in different ways.
I'm fairly new to rails.
I'm unsure where to start.
I feel overwhelmed.
Is this normal?
Since you're beginning with rails, I'd recommend using something that "just works" to get in the habit of testing your code and understanding how to work with your framework. Don't waste your time comparing solutions, choose one and stick with it for this project.
That being said, I really think it depends on your experience developing software:
if you've never used unit tests for your code, learn Test::Unit and consider adopting TDD. Notice that TDD will need you to dedicate a large amount of time to it at first, but that is paid off when you get used to it.
if you have significant experience with code tests and are just confused on how to start with rails, I recommend following through http://railstutorial.org/book. This is a (free) Ruby on Rails book that uses RSpec, Spork and serves as a great introduction
After developing one project from start to end using the testing platform you choose now, you'll have a much better task of choosing the testing framework you wish to use.
I'd also recommend you learn RSpec well before diving into Cucumber.
Sounds like you have option overload. Which is common to most people in a lot of different situations even outside of programming. The absolute easiest thing for you to do, would be to go with what Rails sets up by default, which is called Test::Unit
Their official guide introduces it here: http://guides.rubyonrails.org/testing.html
Once you are comfortable with testing using plain Test::Unit style then I would suggest you explore some of the addons your friend mentioned such as shoulda (https://github.com/thoughtbot/shoulda), and factory_girl (https://github.com/thoughtbot/factory_girl)
Good luck!
But Rspec comes with a whole whack of
other things I need to learn like ...
Actually, you don't need to learn any of those other gems to get started with RSpec. Just go with gem 'rspec-rails, and run rails generate rspec:install to set up your project.
A good way to learn RSpec is to look at the code generated by rails generate scaffold. This creates spec files for controllers, views and routes that deal with the standard RESTful actions.
While learning RSpec you can add in other gems as you discover the need for them. Autotest is essential IMHO. Webrat adds useful matchers for view specs. Factory_girl adds support for factories.
Spork is great, but not really necessary until you have enough specs that performance is an issue.
I feel overwhelmed. Is this normal?
Less of this, more of this :)
The spec library in Minitest is great. I've been able to use it within Rails unit tests no problem. However, Rails functional test inherit from ActionController::TestCase which provides instance variables like #controller in it's setup.
Has anyone been using the Minitest::Spec lib for their Rails functional tests?
If not, I'm considering creating a small library to do just that. I'm not too keen on rspec, and shoulda is starting to shift it's focus to rspec. It would be nice to have something lightweight and built on tools already provided.
Thoughtbot have now split shoulda into shoulda_contexts and shoulda_matchers so the worry about a shift to rspec for thoughtbot doesn't mean shoulda contexts are going away. Just being maintained in the community.
Here's a simple test_helper rig to run functional & integration tests in Rails using spec syntax. Based on a gist by tenderlove, this excellent article about MiniTest with Capybara, & a lot of tinkering & source-poring.
https://gist.github.com/1607879
Maybe try http://metaskills.net/2011/03/26/using-minitest-spec-with-rails/.
I'm writing a tool to run a series of integration tests on my product. It will install it and then run a bunch of commands against it to make sure its doing what it is supposed to. I'm exploring different options for how to markup the commands for each test case and wondering if folks had insight to share on this. I'm thinking of using YAML and doing something like this (kinda adapted from rails fixtures):
case:
name: caseN
description: this tests foo to make sure bar happens
expected_results: bar should happen
commands: |
command to run
next command to run
verification: command to see if it worked
Does anyone have another, or better idea? Or is there a domain specific language I'm unaware of?
Go and have a look at the XUnit suite of test tools. This framework was originally designed for Smalltalk by Kent Beck and, I think, Erich Gamma, and it has now been ported to a whole stack of other languages, e.g. CUnit
You might want to check out CPAN. It does for Perl scripts exactly what it sounds like your utility will do for your app.
Did you take a look at RSpec?