A very interesting article by David Heinemeier Hansson Describing the greater value of system tests over granular unit tests. I’ve definitely seen some of David’s points play out in web systems more concerned about users interacting with the interface than intricate calculations. Although, for those web applications where one small bug might cause significant monetary loss, like in financial related software, seems unit tests would still be extremely relevant.
While writing some RSpec tests today, I ran into an annoying little problem.
One of the functions I was testing was logging output to my console as I ran the tests.
Being a little OCD, all I want to see while running tests are my green dots representing my tests are passing, or the occasional red F indicating I need to look into something. I don’t want to see a boatload of other rouge info. The solution, surprisingly, took me more than a few seconds to find after Googling, so I figured I’d post this quick fix to help any others searching for a fast way to ignore console output from ruby “put” functions during RSpec tests.
If you want to provide a fast way to ignore puts in any test, add this code to the spec_helper. If it’s a one-off fix, just add it to the spec you’re in.
def ignore_puts
before do
$stdout.stub(:write)
end
end
What this is doing is just stubbing out the stdout write method, which, in layman’s terms, is overriding it to do absolutely nothing. The only caveat to note here, is that if you’re using pry to debug your tests (a practice I highly recommend), the debugging console won’t give you any contextual output. So implementing the ignore_puts is something you may want to wait to add if you think you will need to do some heavy debugging in your tests.
I ran into an interesting dilemma today with a controller spec.
I needed to verify that a post to my controller’s update method did indeed update a particular setting on an instance of one of my models. Unfortunately, the controller I was using inherited some before_filter(s) from its parent that called a method that checked for a logged in user.
But all I wanted was to make sure my model’s setting actually got changed!
My good friend and colleague DS filled me in on a little trick that I’d like to share. When testing, it’s a good idea to have factories written for each model. Now, if your model is already created, you’ll have to spin up that factory manually. But how about ensuring your factories are created with each new model you generate?
Enters this nifty bit of code you can add to your config/application.rb file, within the Application class:
I ran into a dilemma with one of my rspec controller test suites while working on a personal website with book and author models.
It occurred as I was using the amazing factory_girl gem, which allows me to pre-define the attributes for a model into a factory to be used over and over again throughout my test suite. That way any time I need to fire up a test instance of a particular model, I can very easily with code like:
As a ruby on rails developer, I’d like to promote the need for testing your applications. No matter how small or large your project, tests will be an invaluable tool to ensure working functionality as you add, delete and refactor code. And I can promise you, during the lifespan of your web app, your code will remain far from static. This is very obvious when you are working for a client. They change their minds constantly. But even if YOU are the client, as I have found myself to be as I work on my own, hobby rails sites, I’ve discovered that even I cannot resist the urge to make changes to my site, some that often break past functionality.
The Ruby Railroad 