[Unit Tests]4 months into the project, with 16 developers, and our build still runs (including dropping and creating 2 postgres databases and 1 mysql db) in less than 50 seconds.
Finished in 6.115697 seconds.
983 tests, 1600 assertions, 0 failures, 0 errors
[Drop and Create 3 databases]
[Functional Tests]
Finished in 5.746835 seconds.
281 tests, 542 assertions, 0 failures, 0 errors
[Integration Tests]
Finished in 0.945832 seconds.
6 tests, 15 assertions, 0 failures, 0 errors
Friday, February 16, 2007
Rails: Unit Testing Update
In the past I've written about unit testing Rails applications and specifically ActiveRecord::Base unit tests. On this topic, I have friends that range from interested to skeptical and probably worse. Since I expect the readers of this blog to fit somewhere in the same range, I thought it might be valuable to post the following stats from my current project. The following is a cleaned up version of our build output.
Subscribe to:
Post Comments (Atom)
Reading your posts made me wonder how you test stuff like custom finders. I actually just asked about it on the rspec list today... http://rubyforge.org/pipermail/rspec-users/2007-February/000787.html I'd love it if you could check that out and comment.
ReplyDeleteWhat is your equipment like? I've been working heavily with mocks (and avoiding the database most of the time), but my number are about 1/4 the speed you're showing.
ReplyDeleteMaybe it's my ancient powerbook.
jchris: intel mac minis (5 months old), 2 gigs of ram, I believe.
ReplyDeletepat: I read the entire thread (as of this moment) and I like David's response: http://rubyforge.org/pipermail/rspec-users/2007-February/000791.html
ReplyDeleteIf you believe, which I do, that you should not connect to a db in a unit test then you can't write a unit test for a method that calls to the db (via the framework).
Also, keep in mind that anytime you are using mocks you are generally specifying how not what. Sometimes it feels uglier than others, but you are always specifying the behavior. This means that mock tests will always be more brittle if the behavior of the class being mocked is changed.