Diary of a Rails rescue project, part 2: Testing. April 16, 2013 As mentioned previously, I’ve been spending spare cycles getting an outdated Rails application up to speed.
Aside from the outdated versions of Rails and pretty much every gem used by the app, there’s a glaring problem: No usable tests. Diary of a Rails rescue project. March 21, 2013 I recently picked up a rescue project.
It’s pretty gnarly–the application was, I believe, originally written in Rails 2.3 (possibly older), was updated to Rails 3.0 at some point, and sat unattended for most of last year. When major security issues hit Ruby and Rails the past few months, there were concerns that the application would have to be taken offline if action weren’t taken. So I agreed to the work. Rescue projects are unique challenges. Moving from beginner to intermediate Rails development. July 05, 2010 I believe that Rails is an excellent way to get started on server-side web development.
The framework provides a good structure that’s easy to understand, and provided you follow some fairly basic rules, you can have a functioning web application up and running pretty quickly. Add to that the gems and plugins that add near-instant functionality, and even newcomers can show off useful, good-looking web apps. Clicking through links and forms on an app you made yourself feels pretty good and should hopefully motivate you to want to do more. If you’re just getting started, you probably watched a video showing how easy it is to create applications with Rails, read books like Agile Rails or Simply Rails, and hacked your way through MVC and model associations to turn your own idea into something you can show off to your friends. 1. Even if you’re working on your own, and even if you never share your code on GitHub, you should use version control. 2. 3. 4. 5.
Buy now. Beginning Rails testing. January 11, 2011 I admit that I was guilty for a long time of not writing any tests for my Rails applications.
My application testing consisted of an unhealthy reliance on in-browser testing, with nothing automated. I blame this on coming from a very unstructured way of developing code before I discovered Rails; I also think the early Rails demonstrations (15-minute blog) and tutorials focused on rapid application development more than the baked-in opportunities to test your code programatically. This wasn’t the end of the world when I had one small app in production, and hardly any users—but as the apps grew in count, size, and complexity, and my user base grew along with them, manually testing every edge case, every time, in a browser became tedious.
It really wasn’t until I read early beta versions of a couple of books on testing that I finally got with the program. Below are five things I did to get in the swing of testing my Rails applications. 1. 2. 3. 4. 5. Everyday Rails Testing with RSpec: The Book is complete. June 13, 2012 On Monday I posted the final, edited version of Everyday Rails Testing with RSpec, available now on Leanpub for $12 US.
First, let me again thank everyone who purchased the early access, beta version of the book. I appreciate the support and all the feedback. As I shared on the Leanpub mailing list yesterday, releasing the book so early in its development cycle perhaps frustrated a couple of readers, but it resulted in a very different (and in my opinion, better) book than I’d originally set out to write. I’m planning to write a more complete retrospective in my personal blog later this week, for anyone interested in the lean publishing approach. Next, let me remind you what’s in the book as it now stands: 115 pages (as the PDF is formatted), 12 chapters (and a short appendix), and a code sample that iterates from chapter to chapter.
Update for Rails 4.0 Availability outside of Leanpub I know that the book isn’t available right now in countries Paypal doesn’t support. Buy now. How I learned to test my Rails applications, Part 5: Request specs. April 24, 2012 So far we’ve added a good amount of test coverage to our contacts manager.
We got RSpec installed and configured, used factories to generate test data, and set up some unit tests on models and controllers. Now it’s time to put everything together for integration testing—in other words, making sure those models and controllers all play nicely with other models and controllers in the application. These tests are called request specs in RSpec—and yes, they can be daunting if you’re still getting comfortable with testing. The good news is you know almost everything you need to know to write a solid request spec—they follow the same describe and context structure you’ve been using in models and controllers, and you can use Factory Girl to generate test data for them. There’s one last component to complete the basic RSpec toolkit: Capybara.
. # Gemfile group :test do gem 'faker' gem 'capybara' gem 'database_cleaner' # more on this shortlyend config.use_transactional_fixtures = true. How I learned to test my Rails applications, Part 3: Model specs. March 19, 2012 We’ve got all the tools we need for building a solid, reliable test suite—now it’s time to put them to work.
We’ll get started with the app’s core building blocks—its models. In this post, we’ll complete the following tasks: First we’ll create a model spec for an existing model—in our case, the actual Contact model. Next, we’ll simplify the process of creating and maintaining test data with factories. We’ll create our first spec files and factories for existing models by hand (though the handy RSpec generators we configured in Part 2 can be used as templates when adding future models to our application). Anatomy of a model spec I think it’s easiest to learn testing at the model level because doing so allows you to examine and test the core building blocks of an application. To get started, a model spec should include tests for the following: This is a good time to look at the basic structure of an RSpec model spec.
Creating a model spec $ rspec spec/models/contact_spec.rb. How I learned to test my Rails applications, Part 4: Controller specs. April 07, 2012 Poor controllers.
As Rails developers we keep them skinny (which is a good thing) and often don’t give them due attention in our tests (which is a bad thing; more on that in a moment). As you continue to improve your application’s test coverage, though, controllers are the next logical chunk of code to tackle. If you’re new to RSpec or Rails testing in general, I recommend reading through the previous posts in this series first: Why test controllers? Following the lead of some prominent Ruby developers I stopped working on controller specs for awhile, in favor of covering this functionality in my request specs (integration tests).
Controllers are models too, as Piotr Solnica indicated in an excellent blog post. Controller testing basics Scaffolds, when done correctly, are a great way to learn coding techniques. How I learned to test my Rails applications, Part 2: Setting up RSpec. March 12, 2012 In this post, we’ll complete the following tasks: Use Bundler to install RSpec and other gems useful in testing Install a test database, if necessary Configure RSpec Configure our Rails application to automatically generate files for testing as we add new features Our application In this book, I’ll be working from a basic Rails 3.2 contact manager.
The application currently has the following features: Anyone can view contacts’ information (in other words, not the most private contact manager in the world) Users may log in to enter contacts Contacts may have multiple phone numbers, via nested form attributes OK, it’s probably not going to replace your current address book—but it does have enough functionality to demonstrate some simple techniques to practice testing (and eventually, test-driven development) with RSpec and Rails. How I learned to test my Rails applications, Part 1: Introduction. March 12, 2012 Ruby on Rails and automated testing go hand in hand.
Rails ships with a built-in test framework; if it’s not to your liking you can replace it with one of your liking (as I write this, Ruby Toolbox lists 32 projects under the Testing Frameworks category). So yeah, testing’s pretty important in Rails—yet many people developing in Rails are either not testing their projects at all, or at best only adding a few token specs on model validations. There are several reasons for this. Perhaps working with Ruby or web frameworks is a novel enough concept; adding an extra layer of work seems like just that—extra work.
I’ve been there. I’d looked at Ruby before, but never had a serious use for it until Rails began gaining steam. That said, early Rails books and tutorials focused more on speed (build a blog in 15 minutes!) Who should read this series.