autotest -rails 22 comments
“You should spend at least half of your time in the ‘test’ directory.” — Jeremy Voorhis
“Quit looking at your web browser!” — Eric Hodel
Web development without a browser?
My development process has recently been supercharged by autotest, a part of the ZenTest package that you can download from RubyForge or install as a gem:
sudo gem install ZenTest
See a Movie of autotest in action
Autotest runs continuously and watches to see what files you have edited. Any time you save a file, it will run the corresponding test within a few seconds. If a test fails, you can see the result immediately. If it passes, you can write another test, then the code necessary to make it pass, ad nauseam.
# Run this inside your Rails app's directory topfunky$ autotest -rails
The revolutionary part of this is that it speeds development by helping you develop without needing to open your web browser! I find myself thinking more about the functional issues that need to be solved rather than the placement of an image or the color of a link.
And since it’s running continuously, you don’t have to wait for your tests to run…they are running almost all the time. When they do run, they often take less time since autotest intelligently diffs the change and runs the test for a single method, when possible.
It makes it hard NOT to do test-driven development. You see the screen sitting there like a hungry fire waiting for another test. Like a fire, it also has an infinite hunger, so you will never beat it.
But the point is…by writing tests you can
- Ensure that changes to your app won’t break other functionality
- Keep yourself on track by focusing your mind on problems, solutions, and the most functional design
- Speed your development by breaking out of the write-refresh-wait-wait-wait-debug cycle
ZenTest also has other tools, but I’m definitely grooving with autotest.
Nuby on Rails
Geoffrey Grosenbach / Ruby / Code / Graphics / Design / Rails / Merb / Javascript / CSS
Manufactured with
Subscribe
Menu
Recent Articles
- Improve Your Technical Slides
- The Third Seattle.RBBQ
- PeepCode is [No Longer] Looking to Hire a Virtual Assistant
- IOTC Open Source Conference in Dublin
- RailsConf Suitcase
- → Older articles
Speaking At
Elsewhere
- PeepCode Screencasts
- Ruby on Rails Podcast
- Rails Workshop Calendar
- Job Leads
- Task Scoresheet
- Podcasting Basics
- Topfunky on Twitter
- Topfunky Corporation
Free Software
This is a must-have for all rails-user. It is stunning .
Steven Baker talked about this at the TDD workshop right after CoR. Very cool.
I can’t seem to find any documentation on using the 4 commandline tools. Specifically, I want generate test stubs with the ‘zentest’ command, but I can find no help. The RDocs just document (sorta) the internal methods. Anyone know where I can find some documentation?
You’re right…there’s not much documentation on the other tools in ZenTest.
I’ll bug the authors, or will figure it out myself and write an article.
Very cool! It’d be cool to have this run in the background and popup a message in OSX when something fails. ;-)
Woah, awesome. Yeah, it seems ironic that your code actually works a lot better without ever looking at the web browser and just writing solid test cases, but it’s so true!
Thx for the link & the mov.
Robby: just pipe it into growlnotify.
By the way. There is stakeout. A OSX only tool which watches for file changes using kpoll; A OSX kernel feature.
It works very well for testing setups similar to autotest and reacts instantaneous to file saves.
Obviously you don’t get all the cool extra stuff ZenTest does for you…
Stakeout sounds very useful for other types of tasks.
You can even have it run a rake task:
→ More info on stakeout
Very cool indeed. I often find myself writing too many tests/code without actually running them until I finish with a particular piece of functionality. Don’t want to lose the creative flow so to speak.
This should be part of every tutorial on installing a Rails development environment.
It would be cool to link this to Growl, so that the output is better-formatted and more human readable.
Ive successfully linked this to Growl, thanks for the tip Scott !
Is there a related article that goes with Eric Hodel’s quote above :)
There isn’t any written evidence, but if you come the the Seattle.rb hacknights, he’ll probably give you that piece of advice from across the room (and other useful advice, too).
His blog is Segment7.
I discovered a great way to make autotest (and other Rails stuff) run much faster than on my Powerbook. Run it on my linux server (fast machine), and mount the working copy via NFS on my Powerbook, where I can then edit the app’s files as usual. Autotest picks up the file changes without a hitch, even though they’re coming via NFS. I’ve found the tests run about 10x faster on my server than on the PB!
Very cool tool!
I’ve saved even more time by adding colour to the output :D
Is there anyway to get this to work with integration testing? I would assume that the integration testing would need to be run just about every single time there was a change to any file.
It would be nice to have that option though.
“Like an infinite fire?” That’s a tad heavy handed, isn’t it? Great write up otherwise :-)
How does auto test know which test to run? If I modify an action in controller A that I have an integration test for named ‘test_checkout_process.rb’, how will autotest know to run that particular file?
It does a fairly simple matchup of filenames…see ZenTest/lib/autotest/rails.rb.
For example, app/models/article.rb maps to test/unit/article_test.rb.
Awesome article! I have been working on implementing ZenTest, but I’ve been having a difficult time understanding exactly how to use all of the features.
Linking to Growl sounds like a great idea… hopefully I can find an equally simple article to get it set up :)
Very good article. Thanks for some sound advice. It’s a topic that all creative industries need to know a lot about.
autotest.rb line 190: Windows doesn’t have a ”~” directory :) – I had to comment this out to get autotest to run.
Great gem though!