There are 5 posts filed in Testing (this is page 1 of 1).
It is easy enough to debug specs on by one. For this you just run the ruby file that contains the spec with ruby-debug instead of ruby:
rdebug spec/rur_spec.rb
But when running via rake, you can’t do this. A simple solution is to add these lines in the spec file you want to debug (or in spec_helper.rb):
require_library_or_gem 'ruby-debug' Debugger.start
And you are in business…
I still get to switch over to rails 1.1. Mind you, I have been running around with my hair on fire doing more mundane things like preparing my tax return.
In building upon that article on integration testing by Jamis, I ran accross an article from Mike Clark is describing in great details how to run your Rails App, without a browser.
And this is just what the doctor ordered for fairly complex test scenarii. Just imagine the possibility of automating full scripts that go across multiple controllers, exercise how your models related to each other…
Plus that app object has got to be useful while debugging!
Along the line of finding a solution for automating your user testing, if writing a script is not your cup of tea, you can use Selenium IDE to help you record your steps in the browser, complete with some assertions. Check out the demo: Automating a Google search
The downside (if that was one :D) is that you need to use firefox.
Download the firefox extension
Fore more details, visit the Selenium IDE site.
glu.ttono.us has posted an excellent summary of his take on Rails best practices.
And I think I need to do some reading, that the second time in as many days that someone mentions Refactoring by Martin Fowler, and this has me intrigued.
My top favorites:
I must have been asleep at the keyboard the first time I read Jamis article on Integration Testing in Rails 1.1. as it didn’t register as being so promising that it was worth a second look.
You can find the full description on Jamis the { buckblogs :here }.
This is going to be an invaluable tool to test my Rails applications. True, it won’t catch the Javascript problems, but it will help find a lot of the integration issues between the various pages and help me exercise all critical use cases. As you may know, no single testing technique can catch all problems (it is really the combination of all techniques working in tandem that help), and this one is going to be a very important one. And we all know that if adding a test is that easy, then there is no excuse for not doing it ;)
In fact, I’m quite excited at the prospect of giving it a test drive! Thanks Jamis!
3/15 update: and if you can’t wait, you can read Damien Tanner’s article on the subject.
Now I just need to figure out how to play with the trunk without breaking my current installation. I’ll cover that when I get to it.
update #2: scratch my previous comment, there is a good description on how to use the trunk, a.k.a. EdgeRails on rubyonrails.com.
