Menu
As a long time php dev and a rails newb I've been trying to get a grasp on tdd/bdd. There are so many tools and methodologies out there that this can be a pretty daunting task. After a lot of reading I came to the conclusion that this would be my preferred method of testing:
Being a total BDD newb, this could be way off base so feel free to offer suggestions on this testing 'stack'.
What I'm really looking for though is an open source project using these tools that I can look to for inspiration.
Tutorials would be appreciated too, but I think seeing a real world project implement all these ideas would be very helpful.
682
asked Jun 17 '11 22:06
This ensures that we keep our code clean, write small amount of code each time, and avoid duplicated code. In this article, we’ll be introduced to the RSpec gem, which is the most common tool for testing Rails applications. There are some common testing types that you’ll encounter on your journey as a developer.
There are 2 main testing frameworks when working with Ruby or Rails code: Minitest comes packaged with Ruby itself and provide a quick way to assert that your code won't fail. You can learn a lot about Minitest while reading Micahel Hartl Rails tutorial. RSpec is a "Behaviour Driven Development for Ruby.
Add the rspec-rails helper to the Gemfile: # Gemfile . . . group :development, :test do gem 'rspec-rails', ">= 3.9.0" end Install the Gems and complete the setup: $ bundle install --path vendor/bundle $ bin/rails generate rspec:install $ bin/rails webpacker:install Let’s generate this model using Rails generator:
Testing is where we spend most of our time as developers. Good testing raises the quality of software, reduces bugs and, in the long run, makes our work easier. In this article, we’ll discuss the basics of testing with Ruby on Rails:
Everyone seems to have their own recipe for testing that works for them. My background is like yours -- long-time PHP developer using no tests (but doing plenty of manual white-box testing while developing). I recently started writing my first production-level, getting-paid-for-playing-with-Rails app. Here are my thoughts after the first three months.
I too found Cucumber to be too complex for me to start with. I struggled with it for far too long before finally realizing that I was just too far removed from the actual testing framework. Once I dropped down to pure RSpec things became much clearer. That said, now that I've written my first app with a robust test suite I think I could probably drop Cucumber into my next Rails app recipe and feel more comfortable using it for integration testing while still using RSpec for unit testing.
I've developed an unhealthy infatuation with RSpec once I finally understood the process. It really is beautiful to run those tests and see all green. Actually, it's even satisfying to see red because it tells me what to work on next.
I'm using the default Webrat for integration tests. I haven't run up against anything that Webrat couldn't solve, but I haven't given Capybara a try either so maybe I just don't know how bad I have it.
I started writing my tests by following along with the Rails Tutorial Book, and in it the author says "Since I’m not partial to separate tests for views or helpers, which I’ve found to be either brittle or redundant, our first step is to remove them." (Page 93, paragraph 2) After writing a bunch of helper methods, I decided to go back and write separate helper tests for all of them. I'm still rolling my view tests into my controller tests, but I could see separating them in my next project. FWIW, I think you really should be writing tests for everything at some level, even if you're just relying on your controller tests to exercise your views, and/or your view tests to exercise your helper methods.
I'm using Factory Girl with this project and I have found it to be very useful and easy to use. I haven't tried Machinist but it seems to be equally popular. One thing I will mention is that when I first started writing my factories I also used the FFaker gem to generate random content into every factory object that I created. This seemed nice at first as the variable content sometimes caused me to find things that I had missed in development (can't think of a good example at the moment, though), but it also meant I had to worry about truncating all of the returned FFaker data to fit wihtin the length constraints in the model. This proved to be too unwieldy in the long run so I removed all of that code and went with using static strings for all my factories, and only for the required fields. Then when I wanted to exercise a specific field I would do so in my actual specs. IMO, your factories should contain only enough data to create a valid object and no more.
As for mocking, I've only found a few places where I needed to mock something, but perhaps I'm too new to Rspec to know that I'm doing it wrong.
And finally, as for specific examples, just look on GitHub for example Rails apps or open source Rails projects that contain tests. Or follow along with the Rails Tutorial Book as I did. Whatever you decide to do, start as close to the metal as possible and then try different gems/plugins/etc, always making sure you can back off your changes if you decide you don't like the results. I found that trying to start with a complete recipe (i.e. suspenders, blue-light-special, etc.) was too overwhelming. By starting with a raw Rails app I was able to try out different solutions (paperclip versus carrierwave, typus versus rails_admin, clearance versus devise, etc.) to see which ones worked for my personal preferences. It's clear that there is no one perfect recipe for a Rails app, and everyone's preferred recipe is just an opinion.
59
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
