Elements of Testing Style
It's been way too long since I blathered on about style issues. Today I'd like to talk about testing style. This article assumes you are already writing tests and already using something approaching a Test-Driven Development process -- I'm not here to argue about process, at least not today.
Today the topic is the actual construction of individual tests, how to name them, how to group them, where to get data from and the like.
I suspect I'll think of five more things right after I post this, so look for an update sometime in the future. The update will also address all the places where everybody tells me that I'm totally wrong.
Topics: Ruby on Rails
What’s In Your Dock: iPhone edition
It's been a while since I've been desparate enough to had a chance to do a nice "what's in your toolbox" kind of post. In honor of the iPhone 3.0 upgrade, and Steve Jobs' liver, let's do an iPhone-toolbox post.
I'm unabashedly happy with my phone, because it's strengths and weaknesses mesh pretty well with my actual needs. It's not that great a phone, but I don't use the phone that much. On the other hand, there's never been a better gizmo for whiling away a long train commute.
So, here's some stuff I use:
Instapaper (free light version, $9.99 pro version currently on sale for $4.99)
Instapaper has probably changed my web reading habits more than any other app since I started using RSS readers. It's so simple that its almost hard to believe how useful it is. When I come across an article on the web I want to save for later, I click a bookmarklet. Later, launching Instapaper on the phone, the article shows up, with the images stripped away, and the text presented in a reader friendly format. (Sometimes you can help Instapaper out by invoking it from the printer-friendly version of a page...)
Using Instapaper has become kind of second nature -- I always have a few articles ready to go. The Pro version adds a few nice features, including control of the display font and the ability to scroll the article by tilting the phone. The tilt-scroll sounds like you'll need to be a gymnast or something to read an article, but in practice it's a super-clean interface for reading long articles and letting the text scroll at your reading speed. Great app.
Birdhouse ($3.99)
Very well designed little app for what seems like a dumb use case -- saving drafts of posts intended for Twitter. I mean, how much do you need to polish that tweet about the ham sandwich you had for lunch, amirite?
But, if you are trying to do a tip a day on Twitter (@railsrx), then having a nice place to store up ideas for future tips is great. The app also works as a slightly structured note-taking app, since it can email it's existing draft population back to you.
Stanza / Kindle (Free)
The two leading general-purpose eBook readers, both of them are easy to use, and manage the task of making text readable on an iPhone. It'd be nice if there was some consistency in formats between the two apps, and also if you could buy books directly from the Kindle App (presumably that's coming).
MLB At Bat ($9.99)
Obviously only if you are a baseball fan, but the app gives you access to live box score and play-by-play data, live audio stream of radio broadcast, video highlights, special goodies like condensed game videos a few hours after games and, plus live video streaming on a currently limited basis. That's a lot of stuff. Add in the fact that the app is pretty enough to have won an Apple Design Award, and it's a pretty fabulous package.
Twitteriffic (Free lite, $3.99 no-ads)
There are something like a zillion Twitter clients on the iPhone at last count, and which one to pick is basically idiosyncratic. It's a mark of how fast iPhone development is going that Twitteriffic 1.0 won an Apple Design Award in 2008 and was completely blown away by newer clients six months later before regaining strong status with the 2.0 release. I find this has a nice blend of features and interface. (Tweetie, which is my desktop client, is also very good on the iPhone).
Of course, this all sounds serious -- the big winners on the iPhone have all been games, there are all kinds of inexpensive, addictive little games I play. Here are a few: Defender Chronicles, The Creeps, Drop 7, Flight Control, Frenzic, Galcon, Peggle, Strategery.
Topics: iPhone
Upcoming Pathfinder Appearances
Here are a couple of upcoming Ruby and Rails-based appearances by Pathfinder personnel:
On Tuesday, June 23, Noel Rappin (referring to himself in the third person) will be the guest speaker at the Chicago Ruby.org monthly meeting. The meeting starts at 6:00 at Chicago Ruby's downtown loop meeting location, see the link for details. The working title of my talk is "I'd Like To Start Testing. Now What?" and it'll be an informal discussion of testing tools and good practice.
The schedule for WindyCityRails was announced this week. The conference is September 12, 2009 at the Westin Chicago River North. John McCaffrey from Pathfinder will be presenting "Super-easy PDF Generation with Prawn and Prawnto", and I'll be up there with "How To Test Absolutely Anything".
Other speakers include Ryan Singer from 37signals, Ben Scofield from Viget Labs, and Yehuda Katz from Engine Yard.
Registration through August 1st is $99, there are a couple of tutorial sessions also available for purchase.
This was a very well-run regional conference last year, and I'm excited for this year's edition. Hope to see you there.
Topics: Ruby on Rails
The Return of the Cucumber
I mentioned last week that the RubyMine post was replacing what I had meant to write about. Well, this week we finally get to it...
It's been about ten weeks since I wrote about Cucumber the first time and the second time. Since then, I've continued to use Cucumber and now seemed like a good time to update some thoughts on how and why it seems to be working for us.
The big headline, of course, is that I'm still using it after ten weeks. I'm pretty quick to abandon tools that aren't pulling their weight, so just the fact that Cucumber is still in the toolbox means that despite the time that it takes to write Cucumber tests and step definitions, I'm finding the process of writing the tests and the tests themselves to be valuable.
Topics: cucumber, Ruby on Rails, Testing
Back To The Ruby Mines
This actually wasn't the post I was planning to write this week, but a couple of days ago I got it in my head to try the latest version of RubyMine, the Ruby and Rails IDE from JetBrains.
Now, I tried this with the beta version back in December, and thought it had a long way to go. However, there's been a lot of online chatter about it over the last few months. (Gregg Pollack was particularly enthusiastic in his RailsConf talk), and I thought I'd go back and try again. And I started Twittering about it again, and got some responses, so I thought I'd do a longer write up.
The executive summary is that I started using this on Wednesday and haven't stopped yet. It's come a very long way, and although there are still annoyances, it felt better to me than the other Ruby IDE's. I think it's not quite as solid as my normal TextMate/termial prompt combination, but it's improving rapidly. Overall, this is the first time that JetBrains' Ruby IDE gave me that pleasant "this is like IntelliJ" feeling.
One thing I definitely learned from my years as a happy IntelliJ user back when I wrote more Java code, is that JetBrains releases often, their betas are usually very solid, and they add new stuff really, really rapidly. So my expectations are high that RubyMine will continue to improve. Continue reading »
Topics: Ruby on Rails
Comparing Ruby Mock Object Libraries
Continuing on the theme of comparing similar things that I started last week, this week I'll be taking on Mock Object libraries.
The purpose of a mock object library is to allow you to create "fake" objects that can take the place of the regular objects in your application during testing (you'll sometimes see them called "test doubles", by analogy with a stunt double, another kind of stand-in).
There are a several reasons why you might want to use a test double in your tests, the two most common are probably these:
- To take the place of a hard to create or expensive to access object or method call, such as a web services call. Using the test double lets the test system pretend that the expensive object is there, but at a much lower time cost.
- To isolate an object being tested from the details of the rest of the system. In Rails, for example, a controller test might create test doubles for methods in the model so that the controller test can pass or fail separately from whether the model implementation is correct.
Ruby's open object model and duck-typing makes creating test double objects relatively easy compared to stricter languages like Java. There are four major mock objects packages in Ruby:
- FlexMock is the original Ruby mock object package
- Mocha is quasi-official in that the Rails team uses it for their tests.
- RSpec defines its own mock package
- RRis the newest entry, with shorter syntax and a couple of new features
Here's a tour of what each package looks like, and when you might use each feature.
Topics: Ruby on Rails
Factory tools for fixture replacement: a comparison
Continuing on the general theme of blog posts that people actually asked me to do... this week, I'll be taking a comparative look at fixture replacement tools. The general request was to have one place that compared the features of the various libraries so that a prospective fixture replacer might make a more informed choice.
So here goes, I'll try to keep the editorializing to a minimum, but no promises.
Fixture replacement or factory tools replace the global nature of Rails fixture data with the ability to easily create new objects based on sample valid data previously defined by the developer. Factory tools have several advantages, including keeping each test independent of other tests, since you are no longer using global fixtures, and allowing the important data for each test to be defined in that test.
Updated to correct some errors caught in the first few comments.
Self-promotion alert: A full description of why to use fixture replacements and an in-depth look at one of these tools is available in the full version of Rails Test Prescriptions available wherever fine PDF books are sold as long as you think the only place fine PDF books are sold is http://www.railsrx.com.
Continue reading »
Topics: Ruby on Rails
Rails Testing Frequently Asked Questions — The Non-Code Version
Between my sessions at RailsConf, and the book promotion at Ruby Learning I've been fielding a lot of questions about Test-Driven Development and Rails. Here are five of the most common general questions.
Self promotional note: many of these questions and more are covered in detail in Rails Test Prescriptions, only $9 dollars for a book that covers all kinds of testing topics...
Continue reading »
Topics: Ruby on Rails
RailsConf ‘09: After the RailsConfening
A rambling set of notes and things while it's still in my head.
Topics: Ruby on Rails
Process, Environment, and Incentives
I was having a conversation with a co-worker this week about the automated build server on a particular project. My co-worker had set up the server to fail the build if test coverage dropped below 100%, and I was less than convinced that this was a good idea.
We didn't debate it much, I wasn't doing a very good job of making my points, and we both had other things to do, but it got me thinking about process, community, and incentives. So I thought I'd ramble on about that for a while.
Thinking about it, I decided that having the build fail on a coverage drop, although I still think it's overkill, is not nearly as important as what happens after the build fails. Is it allowed to stay failed? Does the responsible developer fix it sheepishly? Is the responsible developer forced to wear a silly hat? What incentive is there for the developer to ensure the build status before checkin? Continue reading »
Topics: Ruby on Rails
RailsConf 2009: The RailsConfening
In just over a week, I'll be headed off to RailsConf for my second visit.
Here's an overview of some of the sessions I'm looking forward to.
First, of course, is my own: Below and Beneath TDD: Test-Last Development and Other Real-World Test Patterns. It's at 2:50 on Tuesday, May 5, in Ballroom B. I'll be talking about how Test-Driven Development can fail, how to recognize failure patterns, and how and why to move back to a successful process. No matter what your level of comfort is with testing, I think you'll get something out of this talk. It's going to be fun, and I'm excited about the chance to present.
I'm also going to be giving out free copies of Rails Test Prescriptions (well, it's an ebook, I'll be giving out free licenses). I haven't quite worked out the exact details yet, but it'll be similar to last year's plan, and will involve seeing me or attending my session. Follow the book on Twitter for information about giveaways. Follow me on Twitter for general updates about the conference.
And come up and say hi -- I'd love to meet people who read this blog or the Rails Prescriptions book.
Other talks and sessions that I'm particularly interested in include:
Topics: Ruby on Rails
Static Typing and the Paranoid Style of Programming
I have kind of a long standing rant-thing about static languages vs. dynamic languages, defensive programming, exceptions, and the best use of a developer's time and effort. It's been dormant for a while, but Sharad's comments on static v. dynamic, which I largely agree with, and this short piece by David McLaughlin on defensive programming gave me an itchy ranting finger.
Continue reading »
Topics: dynamic languages, static typing
Nested Contexts and Test Structure
I first started using Shoulda for my Rails tests, it took me a while to really understand how Shoulda wants me to use contexts.
In a traditional SUnit/JUnit test structure, the test setup gets the data in order, the actual test method does something and then tests assertions about the outcome
Continue reading »
Topics: Ruby on Rails
What Makes Code Great?
This post by Chad Fowler about 20 Rails development no-nos caught my eye, and not just because Fowler crowd-sourced it on Twitter. Fowler asked the question this way:
"what's an example of one thing you find in other people's Rails
code that you (almost) always consider to be wrong?"
That's a great question, and he got interesting responses.
I found myself kind of drawn to the opposite questions -- what would I find in somebody else's code that would lead me to consider the code "great". Working from the assumption that avoiding the no-no's on Fowler's list would make code good, is there something beyond the absence of bad ideas that makes code great? Continue reading »
Topics: Ruby on Rails
Again With The Cucumbers
My cucumber obsession continues unabated. I've spent a lot of the last week adding Cucumber to projects, writing about it in a very long section for the Rails Test Prescriptions book, and generally trying to figure out how to use this tool, not to mention trying to figure out why this tool has been so interesting to me this week.
Some follow-up thoughts since last week's post.
Continue reading »
Topics: Ruby on Rails, tdd, Test Driven Development, Testing
About Pathfinder
Follow the Blog
-
Get a monthly update on best practices for delivering successful software.
Subscribe via email
Subscribe via RSS
Categories
Topics
Archives
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Blogroll
Recent
- Elements of Testing Style
- Aesthetics and Web Design
- Asterisk-Java Testing with Groovy
- 3 Misuses of Code Comments
- Fluently NHibernate
- Digging a Hole and Covering it with Leaves — The Software Development Version
- The Importance of User Experience - Do You Understand It in Your Bones?
- Writing Your Own Protocol With NSURLProtocol
- What’s In Your Dock: iPhone edition
- Feature Fatigue













