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!
testing
There are 6 posts tagged testing (this is page 1 of 1).
Selenium IDE
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.
Best practices
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:
- testing of course
- I second Luke. Selenium and Selenium on Rails is a better approach for functional (and user type testing). I’m not saying this should replace it. Use both techniques.
- DRY (Don’t Repeat Yourself)
Fixture variables not created
Given a fixture contacts.yml which contains:
patrick:
id: 1
name: patrick
email: patrick@tes.com
pre 1.0 solutions:
@contacts[“patrick”] #using hash
@patrick #using variable
solution 1:
contacts(:patrick) #using accessor
solution 2:
@loaded_fixtures[“contacts”][“patrick”] #direct access (not recommended)
solution 3:
Edit the test/test_helper.rb and set
self.use_instantiated_fixtures = true
this way the fixture variables are created like they used to.
You can get more details from the man himself (Mike Clark’s Weblog).
Integration Testing in Rails 1.1
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.
Some non-transactional changed tables couldn’t be rolled back
Here’s an other thing that is not supposed to happen, but invariably does.
Playing aroung with Unit Testing in Rails (you are using them, right?), one test fails with:
Exception `ActiveRecord::StatementInvalid’ at
…/active_record/connection_adapters/mysql_adapter.rb:185
- Mysql::Error: Warning: Some non-transactional changed
tables couldn’t be rolled back: ROLLBACK
Turns out that on my OS (debian), the default mysql database table type is MyISAM and it does not support ROLLBACK, try InnoDB instead.
March 12, 2006 update:
In case this is not possible, or too much problem, there is an other solution (albeit slower).
In test/test_helper.rb, change:
self.use_transactional_fixtures = true
to
self.use_transactional_fixtures = false
this way, the testing framework won’t use rollback but drop and recreate the tables each time (which explains why this is slower).