0

We now have a considerable size rails(2.3.9) application with 0 rails test cases. (What???). Yes. It is possible:).

Moving on, if we want to base our testing on one framework, which one should we pick, cucumber, rspec1 or rails built in testing framework?. The reason I am saying only one framework is because of the complexity in learning and managing multiple frameworks for the same purpose.

Q1: Some of the y2009 SO questions recommend using rspec for unit testing models/controllers and cucumber for testing views. Is that (as of 23 June 2011) still a valid recommendation?

Q2: Has anybody managed to build all the test cases they needed on a single framework(say just Cucumber)?, if yes,which one?

Community
  • 1
  • 1
so_mv
  • 3,939
  • 5
  • 29
  • 40

2 Answers2

2

Q1: It depends on your developers. Basically you can test almost the same things with all frameworks. I would personally go with rspec1. You will find many resources for rspec especially for rails 2.3.x. On the long run I would try to migrate the project to rails 3. The longer you wait the more painful it gets.

Q2: No, AFAIK cucumber is used for integration testing. You could just use rspec or testunit but then you would lack integration testing. If you go only for integration testing you would lack unit testing but you need unit (or behavior) tests. Furthermore you should invest some time in mocking frameworks as they will save you much time.

ayckoster
  • 6,707
  • 6
  • 32
  • 45
1

It's somewhat a matter of preference, but of the three I would pick rspec or Test::Unit. RSpec has been criticized for being over-engineered lately, but I really like:

  • the matcher syntax (value.should == 1 vs. assert_equal(value, 1))
  • test names not confined to method names (it "does something awesome" { ... } vs def test_it_does_something_awesome; ...; end)

You can achieve both of these with TestUnit with some supporting libraries with relative ease... but I just prefer to use RSpec.

When you write code and test, usually (always?) it's better to start from the outside in: IE, write an integration test (a logged in user clicks a button to add $5.00 item to cart, then checks out, and pays. His credit card should be charged $5.00). So rather than testing specific class behaviors (as you do with unit tests), you'll want to be creating objects in the database and making get / post / etc. calls that interact with the site in a similar way that the users web browser would, making your test penetrate the entire stack.

Lately I have liked using Steak inside of RSpec for my integration tests (using Capybara to facilitate the web interaction)

Once you build up your outer perimeter, then I would recommend you start focusing on the unit tests.

Unit tests can be fantastic for documenting a class's behavior. I group them around methods and describe what can be passed to the method, and what I expect to be returned.

describe Object do
  describe "#method" do
    it "returns 4 when passed 2" do
      ...
    end
   end
end
Tim Harper
  • 2,561
  • 20
  • 23