Rails fast test suite
Rails convention suggests Model classes that traditionally extend ActiveRecord::Base with the corresponding unit tests depending on the database. I prefer to separate the business from the data access layers by having a few ActiveRecord children handling persistence (not unlike repositories) with the bulk of the application logic residing in classes that are unaware of the database.
I find it useful to add a separate test suite for handling the tests for those classes by creating a new directory, e.g. test/fastunit and a Rake test task (lib/tasks/fastunit.rake) that runs the tests in it.
namespace :test do
Rake::TestTask.new('fastunit') do |t|
t.pattern = 'test/fastunit/*_test.rb'
end
end
Rake::Task[:test].prerequisites << 'test:fastunit'
Adding test:fastunit to the prerequisites of the main test task ensures the suite will be ran as part of the full test build.
One of the advantages to this approach is the instant feedback of running rake test:fastunit - these tests are inherently faster. I run these tests often whilst developing to ensure things are going smoothly and only run the full build before checkins.
This technique renders the built-in test:units task slightly ambiguous as ActiveRecord tests are now presented more like functional tests, which is not entirely incorrect, because they do, after all, hit the database.
August 1st, 2007 at 4:14 am
Good workaround. The root cause is that Rails calls tests unit tests when in fact - because of their database dependency - they are not unit tests but component or subsystem tests. Which, as far as I can tell, cannot easily be changed because ActiveRecord builds the model from a database, contrary to e.g. Grails, which defines the model in code.
Peace
-stephan
–
Stephan Schmidt :: stephan@reposita.org
Reposita Open Source - Monitor your software development
http://www.reposita.org
Blog at http://stephan.reposita.org - No signal. No noise.
August 2nd, 2007 at 10:44 pm
Saying “I prefer to separate the business from the data access layers” is tantamount to saying “I prefer not to use the ActiveRecord pattern.” Refer to the three chapters (17, 18, and 19) completely devoted to ActiveRecord in Agile Web Development with Rails (2nd edition) (AWDWR) (Thomas et al). So if you prefer that kind of separation, something like Og would be more appropriate. For further discussion I refer you to page 160 of Pattern of Enterprise Application Architecture (POEAA) (Fowler et al).
August 7th, 2007 at 2:54 am
I was being pretentious with the book references. Even though separating the business logic from the persistence is no longer the ActiveRecord pattern, the benefit of having a faster suite of tests is nice.
August 9th, 2007 at 1:55 am
An approach I’ve enjoyed thus far is to use a library like Mocha to do things like mock calls to the database or have my controller pretend it has a user logged in.
October 2nd, 2008 at 8:42 pm
[...] with the questioning, because I would point them in the direction of George Malamidis’s work around for fast unit tests. My point is that there maybe a better solution than separating the [...]