I have a large Rails 3 project with lots of reusable code in modules. Tests for these modules are placed in test/lib to isolate them from database-heavy model tests. In order to run these tests automatically along with my unit, functional, and integration tests, I implemented the solution described here some time ago. However, at some point over the last year, either Rake or Rails or both broke this (I'm leaning towards Rails, since the new tasks in the Railties gem look much more complex, with special subtasks derived from the Rake::TestTask class). I've been looking for a new approach, and today I got fed up and started fixing it myself.
Read more...
RailsConf Dispatch - Test Always?
How not thinking carefully about your test suite can hold you back
There were two conveniently sequential presentations today at RailsConf that reminded me of some thoughts I'd had regarding testing: Michael Feathers' talk on legacy code and Glenn Vanderberg's talk on real software engineering. It seems to me that both talks had a theme in common: what is the function of tests? Why do we want them, what role do they play from an engineering perspective in the larger process, and what precisely are they meant to indicate to us?
Michael at one point talked about the expense of 100% code coverage for tests, instead recommending we test the parts of the code that change the least and are most important. Ugly code in legacy projects has utility, he explained, and untested code is a rational response to churn. Afterwards, Glenn discussed software development in the context of engineering principles from older, more established disciplines like structural engineering, finding areas of similarity, analogy, and abject difference. However, his testing point compared experiments in code to experiments in more physical engineering fields, remarking on how relatively cheap tests are for us. I suppose the common thread I found concerned the emphasis on cost: that what it means for us to do our job well is to do it effectively, and not subordinate our conscience and creativity to a mechanical process.
For some background, I've been practicing behavior driven development for a year or two. I love the confidence that testing gives me, independent of the value to the client. Verifying that my code works is fine and all, but what lets me sleep at night is the assurance derived from approaching a problem in a rational, systemic manner. By moving in small chunks and expressing problems in terms I understand well enough to programmatically recreate, I ground myself in a real comprehension of the system I'm building at the most relevant level and stage. I avoid the confusion of jumping ahead, thinking too large scale or minutely, or making unwarranted assumptions that come back to bite.
Read more...
To me, development is all about communication. With clients and other developers, sure, but mostly with the computer itself. I'm trying to describe to the computer how to accomplish a task it does not have any capacity to understand or appreciate. On the other hand, the context of a given problem can be so natural to me that I have a hard time articulating it. Using autotest, I can engage in a sort of conversation with the computer, where it tells me in real time as I program whether it understands what I'm telling it or not.
A Growl notification informing me of test results is great, and I can even tell Growl to play a sound when the notification is ready. But that sound tells me to look for the notification, not whether the tests pass or fail. To make this conversation more fluid, it would be nice if I had not just visual but also audio feedback which told me immediately what the test results were, instead of having to constantly context switch to the test results.
There have been a few attempts to do this already, but they all seem so complex. I found a simple command line sound file player called afplay that makes all this trivial. In your ~/.autotest file, add the following:
Read more...
If acts_as_enumerated classes are borking when you run your tests, here's a nasty workaround I did that just might work for you:
class MembershipStatus < ActiveRecord::Base
if RAILS_ENV == 'test'
def self.[](label)
case label
when :pending
MembershipStatus.new(:id => 1)
when :accepted
MembershipStatus.new(:id => 2)
when :denied
MembershipStatus.new(:id => 3)
when :invited
MembershipStatus.new(:id => 4)
end
end
else
acts_as_enumerated
end
end
