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
Aesthetics and Web Design
Patrick Lynch over at A list apart has just written a great article about the role of aesthetics in web design. In it, he specifically deals with the question of how much of a role visual aesthetic design should play in the design of web sites. To answer the question, he delves into the somewhat controversial notion of visual decision making--the idea that aesthetics can help users in their decision making and aid in general website usability.
The article is written in response to assertions made by one Jakob Nielsson, who, citing numerous eye tracking studies that his team has performed over the years, concludes that any images, or other elements on a web page that are not integral to the site's content or function are routinely ignored, and hence superfluous or even distracting.
But the author says no. Aesthetic elements on websites, while not recognized as helpful in eye tracking studies, do perform a vital role in website usability. Mr. Lynch cites the work of early 20th century Gestalt psychologists that have proven that the brain responds to images in milliseconds. And more recent studies of web sites suggest that users make visual impressions of pages in less than 1/20 of a second--before eye tracking movements begin--and that those impressions more or less stay through the length of the visit.
He goes on from there about why "attractive things work better", describing Don Norman's three levels of human psychological processing (Visceral, Behavioral and Reflective), and why they all work together to create an impression of a product like a website.
Read the full article over here.
Asterisk-Java Testing with Groovy

Recently I have taken a bit of a detour into the world of telephony, working with Asterisk-Java, which by itself is a very valuable tool, and worth knowing a bit about if you are integrating a system with Asterisk. While it is a Java-based library, I am integrating it into a Grails application.
We have a fairly comprehensive suite of unit tests asserting that desired behaviors are triggered upon certain events initiated through the Event API. This is made even easier, as usual, with Groovy-- specifically on the testing front. Here I show two hypothetical test cases, followed by supporting code that works specifically with the Asterisk-Java classes...
Topics: asterisk, Grails, Groovy, telephony, Test Driven Development, unit testing
3 Misuses of Code Comments
Not many people talk about good practices to use for comments in code. Many people see them as an extra or freebie, so not a lot of thought gets put into them. The truth is, though, that comments are a great tool for giving insight into the thought process when the code was being written. Unfortunately like any tool, comments can be misused.
Here are three of the most common misuses of comments which I tend to run into.
Fluently NHibernate

Fluent NHibernate is an extension of the widely used and very popular NHibernate framework for Microsoft .NET. It is an open source framework that sits on top of the NHibernate layer and utilises all the core NHibernate methods. This framework provides an alternative to the standard XML based mappings (.hbm xml files) of NHibernate. It lets you define the NHibernate mappings in strongly typed and concise C# code. For those who are new to NHibernate, here is more information.
Topics: Data Mapper, Fluent, NHibernate, ORM
Digging a Hole and Covering it with Leaves — The Software Development Version
Whenever I hear the plan uttered (and in my Wall Street consulting days, I heard this a lot), that we should build an HTML (or Flash) prototype, impress the client and then fill in the back end, an unwanted image comes to mind. We're digging a hole (the missing 80% of the back end) and covering it with leaves (the HTML prototype) in the hopes that the client will fall in (impressing the client).
No, this isn't a rant about HTML, Flash or paper prototypes. Those have their place, to be sure. We use them every day in our own software development practice, but they have a short lifespan -- usually less than an iteration on the way to delivering the actual feature that it is prototyping. But when the prototype takes on a life of it's own and becomes a long-term deliverable, that's when you run into problems. What are these problems? They aren't as numerous as fall leaves, but there are plenty.
Topics: Agile Development, Prototyping
The Importance of User Experience - Do You Understand It in Your Bones?
Business Week had an article earlier this week on Cloud Computing that made a complete hash of the subject. However, there was one paragraph that was right on the money:
Apple and Google understand in their bones that simplicity and ease of use are essential to broad adoption of products and services. That lesson doesn't come so naturally to Microsoft and IBM.
That's why we integrate user experience design into the agile development process, and that's why we advise our clients to release the simplest software they can early, so they can learn from real user feedback and continue to make improvements based on that learning.
It's like John Gruber writes over at Daring Fireball:
“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”
—John GallIf there’s a formula to Apple’s success over the past 10 years, that’s it. Start with something simple and build it, grow it, improve it, steadily over time. Evolve it.
Do you understand that in your bones?
Writing Your Own Protocol With NSURLProtocol

I have a native iPhone application in development which requires me to interact with a server that uses a stateful protocol over a persistent connection to transfer messages over the wire. This is definitely not a trivial application to write, even though the UI itself is very simple.
The Problem
Stateful protocols and persistent connections are often interrelated, but not by design. My first problem was to divide the original problem in two: how to manage the persistent connection, and how to handle the underlying protocol so that the stateful aspects did not bubble up throughout the UI.
Topics: iPhone SDK, NSURLProtocol, obj-c
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
Feature Fatigue
Your project is going along fine. After the initial bumps, the team has reached max velocity and is running through story points like there’s no tomorrow. The demos are a success, with the client loving how everything is coming together. Communication between the team members and the client is working well, with enough give and take that all sides feel like they have a genuine stake in the project. In fact, the goal posts are in sight and we’re already scheduling a release plan. And then the client asks for one more feature. Not a tweak of something already built, but a new feature that has to seamlessly incorporate into the application and not look like a last minute add-on.
The initial response? The team to comes to a screeching halt and devolves into something resembling the stages of grief. Continue reading »
Topics: project management
ChicagoRuby meeting ‘Test Prescriptions’ recap

The ChicagoRuby users group (not to be confused with chirb.org another great Chicago Ruby user group) held their second meeting at their downtown location.
While the meetings out in Elmhurst are always informative and helpful, the downtown location may allow for a bigger crowd, and the weekday time might work better for more people. Plus, the Illinois Technology Association - Tech Nexus is right next to Union Station which works great for people that still have to go out to the suburbs.
Noel Rappin's talk covered some of the most common questions he gets through the Pathfinder Development Blog, and his own site RailsPrescriptions site RailsRX.com dedicated exclusivly to testing.
There's too much detail to cover here, but at a high-level, Noel covered:
- The why, how, when, and where questions that make the foundation of a good testing approach
- Testing techniques for legacy projects
- A good review of the different testing frameworks, what their differences are, and some discussion about each (test::unit, shoulda, rspec, cucumber)
- A solid review of different factory tools that go beyond standard fixtures (Factory Girl, Fixture Replacement, Machinist, and Object Daddy)
- Strategies for migrating from Fixtures
- Differences between the mocking frameworks: Flexmock, mocha, rspec, and RR (double ruby)
- Finding the right balance, and avoiding the pitfalls of 'over mocking'
- Cucumber testing workflow (and where cucumber doesn't work well)
The audience seemed to have a wide range of experience, but all had opinions to share about what they've learned about testing. After the talk everyone seemed fell into small groups to network and exchange ideas and contact info, and a group gathered around Ray and Noel as they tossed around some ideas on potential future meeting topics "Ruby IDE/Editor review", "Rails Jumpstart", "Coding Dojo".
The organizers took a stab at hosting the meeting virtually over gotomeeting (not sure if it was recorded or not).
Their next meeting is scheduled for July 18th, details can be found in their meetup.com group.

The organizers of the ChicagoRuby.com group are also the organizers of the 2nd annual WindyCityRails Conference right here in Chicago, on Sept, 12th, which Noel will be presenting at.
Topics: chicagoruby, chirb windycityrails, factory, fixturereplacement, fixtures, flexmock, mocking, rails, railsrx, rspec, ruby, shoulda, tdd, test::unit, Testing
Mowing the grass, Revisited
A few weeks ago Alice Toth and I had a conversation about how we can better serve our clients, and while we normally delve into project efficiencies like communication, developer training, and good QA practices, this time we both concluded that we need to do a better job of helping our clients reach their goals in the most efficient way possible, and sometimes that means talking them 'down' from the specific implementation idea they have, and finding a faster way to get there.
I said that one of our challenges is that sometimes our clients feel they've hired us to just 'Mow the Grass', not discuss the landscape architecture, so we're not always in a place to be heard when it comes to discussing the fundamentals of a project. Alice wrote a nice post about what 'Just Mow the Grass' meant to her, and the strategy she's devised to find a nice middle ground.
Here's how I see it
Agile Fundamentals: The Feedback Loop
When you improve a little each day, eventually big things occur. -- John Wooden
A few weeks ago I had a discussion with some colleagues on the adoption of Agile within large corporations. The consensus was that Agile was almost always adapted rather than adopted -- that is, companies exclude those practices that conflict with corporate culture, modify those that seem too impractical or wasteful, and sometimes substitute those internal practices that seem a decent and familiar substitute.
Various schools of Agile thought have different reactions to this adaptation, all negative. The XP folks particularly don't like it.
These [thirteen] practices support one another...and thus care should be taken when modifying any of them, or deciding not to include one or more of these practices in a project.
I agree that it definitely helps to follow a particular Agile approach closely in the beginning. Once you have the basics down, you can start to improvise. But it helps knowing the fundamental principle which, in my opinion, underlies all of the agile practices, no matter what the flavor. So, the first three commandments of Agile software development are:
- Feedback loop
- Feedback loop
- Feedback loop
Topics: agile, Extreme Programming, Feedback Loop
Why I love the Internet, part 87
Check out the reader comment on this characteristically astute Dvorak screed from 2007. Kudos to MarketWatch for giving readers a voice equal in visual prominence to the headline of the column. Click to view in all its full-sized glory.
via Daring Fireball.
Integrating Design and Agile Development
If you liked my colleague Alice Toth's presentation on Agile Requirements, you'll like her talk on integrating design and agile development:
AGILE AND ME a story with just enough documentation.
A typical waterfall project produces pages and page of end-to-end requirements for the entire project as it is envisioned (but not necessarily as it will be built). The people compiling these requirements are, of course, part of an assembly with only the most cursory involvement with others outside their department. After all 9,238 lbs. of paper are heaved over the wall with a hearty “good luck!” and a cheery wave, the silos are once again in place and silence is golden.
While agile was taking hold of development, design was still stuck in the waterfall method. So why not blend the two and run the entire project in an agile fashion, starting with requirements? Here's how we do it at Pathfinder:
Like what you see? Check out more of Pathfinder's presentations, whitepapers and articles here.
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







