The gem calculates the APR and monthly payment for a mortgage in the United States.

Calculating the monthly payment is straight forward.

C = Loan amount

E = Extra costs

r = monthly interest rate = interest rate / 1200

N = amortization term in months

An iterative approach is needed to find the APR. The equation for the APR follows.

a = APR/1200

N = amortization term in months

P = Monthly payment (including all fees paid by borrower)

C = Loan amount

The following graph shows the APR calculation plotted for N = 360, P = 2500, and C = 400,000. The APR is where the line crosses the A axis.

I chose the Newton-Raphson method to quickly find a precise solution.

The MortgageUtil.calculate_apr method provides a starting value of the interest rate, which makes the Newton-Raphson converge on a accurate solution between 1 and 3 passes.

Installation

% sudo gem install gemcutter

% gem tumble

% sudo gem install mortgage_calc

Example

Related posts:

1. Launched: Rapid Reporting Employment Chek
2. Installing Edge Ferret/acts_as_ferret
3. Rails Performance, Code Metrics, and Locking Down your Application: Tips & Tricks from Windy City Rails 2008

Tests

Tests can prove to be major hurdle in upgrading Rails applications.  In our specific case,  close to 70% of the tests were either broken or failing due to a number of reasons.  Actually, the number of broken tests was way way greater than failing tests which led us to think the changes in the Rails testing API caused most of these issues.  Some of the issues were also caused by a plugin or gem that was used to support the tests not being compatible with the new API. It took us quite a bit of effort to figure out the reasons for the issues and also find the fixes.

Plugins

I think this is other major pain point. If your application uses a bunch of plugins to support what it does, then be wary of the roadblocks they can pose when it is time to upgrade Rails or Ruby in your application.  The problem mostly arises because of the fact that the community or the user group that built the plugin dont continue to support it or doesnt bother to make it compatible with newer versions of Ruby or Rails. In situations like these, you get thrown into a state of dilemma thinking about whether to write a new plugin to replace the existing one or fix the existing one both of which could be time-consuming.  It makes sense to spend time finding about what exactly is the need for the plugin in the application and if it is indispensable etc before making a wise decision.

Deploying the upgraded application

Though this may not be as hairy as the first two, it could be still prove to be a challenge especially when your the application server is changing (Mongrel -> Passenger).  I think it is important to ensure the script is modified appropriately and is tested adequately in your staging environment before you deploy the upgraded application to the real-world.

Session handling issue with Rails 2.3

For the benefit of Rails community out there, I d like to briefly recount one of the problems that caused me a quite a bit of headache during the upgrade.  The application in question is a content management website with multiple subdomains. The issue that I saw after the upgrade was after user logged into the one of the subdomains in the site and navigated away to a different subdomain, the user got logged out. When the user returned to the subdomain where he logged in originally, he was logged in again.  After several hours of effort trying to debug the issue (at one point,  I was even thinking about stripping out Restful authentication and plugging in Authlogic), this post saved the day for me.  It boiled down to setting this in the <environment>.rb file for the different environments :

config.action_controller.session = {
  :domain => "<root-domain-name>"
}
 

This allowed the session information to be persisted across multiple subdomains of the site.

Some Advice

• Generally, the amount of effort to upgrade is going to be directly proportional to the time between the upgrades. So, upgrade your application often!
• When choosing plugins or gems to support your application, consider the upgradability of these before you decide to use them!
• Last but not the least, spend atleast 25% of the time necessary for the upgrade itself to estimate how long it might take to get it done

Related posts:

1. Testing various roles in ruby on rails
2. “Developing iPhone applications using Ruby on Rails and Eclipse, Part 2: Displaying iPhone content to the client” Also up on IBM Developerworks
3. “Developing iPhone applications using Ruby on Rails and Eclipse, Part 3: Developing advanced views for iPhone” now available on IBM Developerworks

We're currently in the process of interviewing candidates for 1-2 Senior, and 2-3 junior level Rails Developers, and I'm wondering about the skills that are most critical, and how best to identify the best candidates.

My normal interview process flows like this:

1. Quick Phone screen evaluating basic development skills, background, availability, personality
2. Basic coding problem (less than 1hr to complete)
3. Phone call to review coding problem, 'how would you handle X?' questions, etc
4. On site interview targeting: Communication, Communication, Communication, (and tech)
5. Final decision

Independent of the language they will be working with, I've found decent success with having candidates answer some standard dev questions, solve a basic coding problem, and demonstrate their ability to whiteboard a design.

The problem is that it doesn't scale. When we've opened up positions in the past, either Senior or Junior, there have been so many applications that its hard to contact them all. This leads to a reshuffling of the tasks and matching criteria, in an attempt to identify the 'best' matches, and 'filter out' the others.  So instead of calling each candidate first, we might simply reply to them with the details of the coding assignment. I've seen 40 people send the "I'm an extremely hard worker, very interested in your position and would do anything to join your wonderful company" cover letter and resume, and then get whittled down to only 10 candidates that actually submit the assignment.  (Note to applicants: 'showing up' is an important first step!)

I came across an interesting post titled '11 tips on hiring a rails developer' which mentioned some 'filtering' criteria to identify the best candidates

You can read the full description of each one, but there are a few of these that I wanted to highlight:

1. Don't use Monster.com or recruitment agencies.
2. Poach Talent from other companies!
   
3. Don't hire someone that doesn't know Rails at all.
4. Look for open source contributions.
5. A personal Rails blog is required.
6. A university degree is not important.
7. Be wary of holes in proficiency.
8. Avoid brand-name superstars.
9. Hire perpetually.
10. Have a company Rails blog
11. Special compensation.

So each of these tips is meant as a heuristic or proxy of the true underlying ability. Any time you are making generalizations you are going to miss out on a few exceptions, but hopefully you end up with what you are looking for.

Starting with the most controversial first, (#5) while I like the idea of giving a strong preference to someone that has a rails blog, and loves  Ruby, Rails, and Web Development enough to be opinionated and spend their own time ranting about it, I'm not sure I could make it a filtering criteria. Doesn't that seem a bit strong?

I feel the same about (#4) Open Source contribution. I think its great if they have it, but I'm not sure I would reject any candidates that haven't contributed to open source.

While I've met many systems administrators that (#6) don't have a degree, and are very good at their craft, I haven't really encountered many solid developers that don't have a degree. That's not to say they aren't out there, I'm just saying I've never encountered them, and I'm reluctant to use it as a filter. Do you think that there are many strong Rails developers out there without degrees? (I don't care if they have a CS degree, but I think I prefer that they have some kind of degree)

As it relates to (#1) and (#11), I know for sure that the economics of finding a candidate through your own network and contacts can be less expensive than the recruiter fees (assuming you find a decent candidate and don't waste a lot of your own time doing it), and if you are able to find someone directly, it frees up cash for such amenities as 'New Macbook Pro', 'RailsConf', and 'Fridge full of XXX'.

If I was in charge of everything

I really like what Andy Singleton describes regarding how his team at Assembla is organized and tackles Agile Development, and on the right project, I'd really like take his advice and try this one:

"Don’t interview. Just pay people to join a project, pull a task from the queue, and find out what they can do."

Anyways,  I'd be very interested in your thoughts regarding what makes for a Solid Rails developer, where you find them, how you keep them, and what you've learned.

(Oh, and if you know any passionate Rails Developers in the Chicago area, send them over!)

Related posts:

1. 20 useful Facebook/FBJS developer resources
2. Faking the art of interrogation
3. Interview: Songbird developer evangelist Stephen Lau

A lot of pair programming chatter this week. Starting with a New York times article describing pair programming at Hashrocket. It's an interesting article, with a tone that could be described as "anthropologist describing the strange, yet quaint customs of the native tribe"

Obie Fernandez followed up with a list of 10 reasons why pairing doesn't work in most cases. It's actually a list of the things that Hashrocket does to support pairing, although entries like "2. Most software developers just don't want to work that hard" and "1. Most software shops don't really care about excellence" do have a certain, "aren't we great" vibe to them, causing Mike Gunderloy to dryly observe: "Funny, Extreme Programming Explained never said anything about fancy hw or being awesome as a prerequisite for pair programming."

C'mon Mike -- everybody knows that being awesome is a prerequisite for everything in XP.

Josh Susser adds that pair programming isn't right for all projects, particularly projects that have long compile times that force the pair to stare blankly at the screen.

I'd also add this interview with Kent Beck because a) every programmer could use some more Kent Beck in their life and b) because he talks about XP as being concerned with the the social context of programmers, with pairing being a part of that.

Now you are caught up. Here's the part where I talk.

I've had a running debate with Dietrich for two years now. He thinks that Pair Programming is the number one most important part of an agile team. I think it's testing. That said, I do think pairing can be a nutritious part of your agile breakfast. But it's tricky to do right and easy to do wrong.

Pairing is for the long haul. Like pretty much everything in the Agile toolkit, the real gain in pairing happens over time and is hard to quantify because it's the absence of friction later in the project. Code is cleaner and easier to change. System knowledge is more distributed, so you are less likely to freak out when Fred catches H1N1 a week before.

Actually, I'd describe most of the XP practices as "we thought we were trading short-term productivity for long-term productivity, then found that we got short-term gains as well." Certainly can apply to TDD.

Project size and make up matters. A team of three developers, for example, is a challenge for an always-pairing environment. Even a team of two is a problem -- some tasks really don't lend themselves to pairing. If people on the team also has non-developer responsibilities, that's another challenge.

Some people really don't like it. And I think it's glib to say "those people are lazy" or "those people don't care about excellence". Even I find pair programming really tiring, but in a "I worked hard today, plus I had to deal with another person all day." It's not unusual for programmers to be very strong Meyers-Briggs introvert-intuitives, and it's not surprising that personality type would find pairing a challenge. It's not insurmountable, but you do need to structure the pairing with people in mind -- the Hashrocket 25 minutes on/ 5 minutes off thing is a good start.

While I'm here, I think you can really overstate the "people work harder with somebody next to them" thing. Pairing is great and helpful because of the continual review and talking about what you are doing. Conceiving pairing as a way to use peer pressure to keep your coders off of Twitter is, I submit, not very much in keeping with the spirit of the Agile Manifesto.

The physical layout is really important. A lot of Obie's piece is about this. I just want to emphasize first that pairing is a lot louder than solo programming, and this can be an issue in open office environments, and also that pairing really does work better on a neutral environment that isn't either developer's home machine.

Pairing is hard to reconcile with offsite practices And I don't mean just when you're working with six guys in Krakow, but also any kind of work at home, flexible hours, programmer-friendly kind of time structure is a real challenge to integrate with pairing.

Hmm... A lot of challenges, not much guidance. Which matches my feelings. When put in the right context, pairing is fantastic. But the context can be elusive, even for people with the best of intentions and talent.

Would this have been a better blog post if I had paired with a co-worker?

Related posts:

1. The Importance of Pair Programming
2. Growing Into Pair Programming
3. Pair Programming with VNC

If you're an ambitious new Rails developer in Chicago who wants to work along side Dr. Noel and our other sage Rails developers, check out our Rails Internship.

Related posts:

1. Why Chicago is Rails-town, USA
2. Summer Software Development Internship
3. Selling colleagues on progressive enhancement

The problem: I needed to display a warning to a user if the data they were looking at was more than 90 days old.

The solution: Create a method that takes 2 dates (either DateTime or Time), and returns the number of days, or hours between them.

  def self.difference_in_dates(date1, date2, unit = 1.day)
    return nil if date1.nil? || date2.nil? || unit == 0
      (( date1.to_time - date2.to_time ) / unit).round.abs
  end

The problem was simple enough, and my tests were all passing, so I moved on to my next task.

That code has been out in production for several months, but earlier this week, a new developer told me he got an error when running the test:

  NoMethodError: undefined method `to_f'
    for Mon, 21 Sep 2009 14:29:38 -0500:DateTime

(we're running this in Rails 2.0.2)

I looked at the code, knowing it was working before, ran the unit tests myself, and didn't see the issue. Now I'm on Windows and everyone else is on a mac, so as soon as I run into an issue that no one else has seen I want to prove if its a Windows problem. But wait, this test has been running in our Continuous Integration server (Hudson) for months, and no one else on the team ever had any issues with it, and the code has been working in production without any errors in the logs.

I jumped into rails script/console to see what's up, and here's what I found:

 >> x = DateTime.now
=> Wed, 23 Sep 2009 00:00:00 +0000
>>; x.to_time
=> Wed Sep 23 00:00:00 UTC 2009
>> x.to_time.to_f
=> 1253664000.0

Which is what I expected, but when I asked the other developer to run that same instruction, he got an error.

>> DateTime.now.to_time.to_f
NoMethodError: undefined method `to_f'
  for Mon, 21 Sep 2009 14:29:38 -0500:DateTime

What's up with that? We're running the same code, and all of our libraries are the same version. Looking at the date value in his error, I saw the timezone, and decided to try this variation locally:

>>  x = DateTime.parse("2009-09-21T14:29:38-0500")
=> Mon, 21 Sep 2009 14:29:38 -0500
>> x.to_time.class
=>; DateTime

So I'm gathering that when there is a timezone and you ask DateTime.to_time, its just going to give you back a DateTime.
I wasn't expecting this, and its exactly why my code was failing, because sometimes the DateTime.to_time will return just a DateTime object. The Rails 2.0.2 docs do state this:

to_time()
Attempts to convert self to a Ruby Time object; returns self if out of range of Ruby Time class If self has an offset other than 0, self will just be returned unaltered, since there’s no clean way to map it to a Time

Ok, so I guess I have no excuse, its written right there in the docs, but I guess I, didn't really look at the docs for the to_time method, or if I did, I didn't really get what it was telling me. Either way I have a problem that isn't going to change.

When I asked my colleagues at Pathfinder, they all said "Why do you need to do that?" and "couldn't you find a gem or plugin that does that already?"

Which is a solid point. If you are doing something as common as checking for the difference between two dates you should expect to see either some straight code examples of the best way to do it, or a plugin or gem that solves that problem. I'll need to dig into this a little further, but for the moment I simply updated the code to:

  def self.difference_in_dates(time1, time2, unit = 1.day)
    return nil if time1.nil? || time2.nil? || unit == 0
    (( time1 - time2)  / unit).round.abs
  end

and I looked through the places I was using this code and made sure I only passed in a Time object, so now I've 'fixed' the bug so that the tests don't fail for anyone else, and I've bought myself some time to figure out what's the best course of action.

But I'm still curious why DateTime.now behaves differently depending on OS? What's going on there?
I jumped on to our build server (CentOs) and ran DateTime.now, and see no timezone, and that's why the tests don't fail there.
I jumped over to my heroku server and saw that DateTime.now includes a timezone.

Wondering what the os was I ran:

`uname -sr`.chomp.strip
"Linux 2.6.18-xenU-ec2-v1.0"
>> `cat /etc/issue.net`
=> "Debian GNU/Linux 4.0"

So what dictates the Date and Time setup? Is it purely an OS thing, or is it just a component of how time is setup on the server?

I jumped over to another Debian box, and there DateTime.now doesn't include the timezone, so now I'm thinking that its not as simple as just the OS, but something else. (please someone, enlighten me!)

Conclusion: Don't be an idiot
I did a few things wrong here, and I deserve to be flamed for it:

1. Read the docs, understand the code you are relying on. In most cases, ruby and rails just does what you'd expect, but its still worth reading into, even when things seem to be working just fine.
2. If the problem you are trying to solve seems common, google around, ask others what they have done, dig into the framework, etc. Assume you aren't the first to run into it.
3. If it seems that what you are doing isn't common, or isn't handled in the frameworks/libraries you are using, perhaps it means you are looking at the problem the wrong way and there is another, simpler solution out there.
4. Test your assumptions. I will say that at least I had tests that covered my assumptions, and failed when they weren't true. I may not have written the best solution, but at least it worked on every system we deployed it to, and never failed in production

Related posts:

1. Ruby on Rails with Windows – How I made it work
2. edge case city: requirements and testing dates for HR business logic
3. Rails Test Prescriptions is now on sale

Please continue reading after the next sentence.

I installed Snow Leopard a couple of weeks ago.

Wait -- don't stop reading. This isn't a post about how to install MySQL or a post about whether or not Snow Leopard is the Greatest Thing Ever. There are plenty of other places on the Internet where you can get that information.

I wanted to talk about two cool corners of the Ruby universe that I started using as a result of my Snow Leopard installation: MacRuby and RVM

RVM: Ruby Version Manager

One of the Ruby changes in Snow Leopard was an upgrade of the system Ruby version to 1.8.7. All fine, except that one of the projects I work on is on an older version of Rails that is not compatible. Clearly, I needed to get an 1.8.6 Ruby on my machine, ideally without messing up the system installation that other applications are using.

Enter Ruby Version Manager (RVM), a handy command line tool for installing and managing multiple Ruby interpreters on your system. In theory, usage is as simple as this:

$ gem install rvm
$ rvm-install

At this point RVM asks you to make a slight change to your shell files. Then just this:

$ rvm use 1.8.6

"But you didn't have 1.8.6", I hear you cry. True. RVM will go out, download, compile, and install Ruby 1.8.6 to my local machine without interfering with anything else on the system (it installs in ~/.rvm). You can install Ruby 1.8.x, Ruby 1.9.x, Ruby Enterprise, JRuby, Rubinius, and (I think) MacRuby.

(Okay -- that's the ideal. In practice, it took a little bit of system tweaks and command line tweaks. Mike Gunderloy's Snow Leopard guide was helpful here. Although I've been able to get all the main Ruby versions to install, I'm still struggling some of the more esoteric version. Once installation is done, the command line interface is really good and things just work.)

Now, the Ruby in my shell is the new 1.8.6. But any other running terminal shells are unaffected -- especially helpful if you are working on multiple projects. Each Ruby maintains its own Gem listing, although there's work ongoing to make it easy to share gems.

To get back to the system Ruby, just

rvm use system

You can also specify any Ruby version as the default.

This is outstandingly cool, not just to solve my problem, but also as an easy way to create a harness to test your Ruby program or library against multiple Ruby setups. There are other useful features about setting different versions and managing shells, check it out.

MacRuby

Here's the thing. For the last several years I've had this script that communicates with iTunes via AppleScript, and creates a bunch of random playlists according to criteria that is a bit more complex that an iTunes smart playlist. For instance, it can create a playlist made up of two-song blocks by the same artist. Okay, it's wildly overdone, but I like it.

It broke in Snow Leopard. I don't know why. It seems like the Scripting Bridge framework occasionally decides to go out for a cup of coffee, and my script times out.

This seemed like as good a time as any to investigate MacRuby. MacRuby is an implementation of Ruby in Mac OS X Objective-C. Unlike a lot of hybrid language/vm tools, MacRuby gives you direct access to the native objects. So, if you ask for a string, you get an object that acts as both a Ruby string and a Cocoa NSString, responding to methods of either. MacRuby uses Ruby 1.9 key/value arguments to translate Objective-C method names.

[person name];
[person setName:name];
[person setFirstName:first lastName:last];

In Ruby (this example is from a tutorial on the MacRuby site)

person.name
person.setName(name)
person.setFirstName(first, lastName:last)

Unlike regular Ruby, the order of the keyword arguments must match the Cocoa method selector.

For most people, this allows writing Cocoa applications in Ruby, including integration with XCode and Interface Builder.

That's extremely useful, and I plan on trying it soon. For my purposes, the point is that it uses the Scripting Bridge directly, and I hoped that would allow it to bypass whatever weirdness was breaking my original script. (The original script was in Python, but I had a 75% functional Ruby version that I never actually built the I/O on, so it was largely a matter of learning the MacRuby way to communicate with iTunes.) Here's a sample, cobbled together from various parts of the script:

def itunes
  @itunes ||= SBApplication.applicationWithBundleIdentifier(
    "com.apple.itunes")
end

def library
  @library ||= itunes.sources.objectWithName("Library")
end

def all_music
  @all_music ||= library.userPlaylists.objectWithName("Music")
end

all_music.fileTracks.each_with_index do |track, index|
  # stuff here
end

def create_itunes_playlist
  playlist = itunes.classForScriptingClass(
      "playlist").alloc.initWithProperties(
      {'name' => name})
  library.playlists.addObject(playlist)
  playlist
end

#chosen_tracks are my object wrappers around Cocoa
#itunes_track is the actual cocoa object
playlist = create_itunes_playlist
chosen_tracks.each_with_index do |track, index|
  track.itunes_track.duplicateTo(playlist)
end

Overall, everything works as advertised (it seems as though MacRuby is better able to deal with whatever happens to cause the Scripting Bridge to take a nap. I'm using the pre-release MacRuby 0.5, so there's the occasional feature glitch (gem installation is a little dicey, for example). But the MacRuby team is actively, even furiously, pushing forward, and this looks like it'll be very useful, very soon.

Related posts:

1. Keeping Up With The Joneses: Keeping Rails and its extensions up to date
2. Rails Development on Windows: Native or Virtualize
3. Installing Edge Ferret/acts_as_ferret

Sometimes I write these just for me.

As I've mentioned a couple of times, tomorrow I'll be speaking at WindyCityRails, and I need a checklist of all things I don't want to forget, and all thing things I want to do to make the talk great.

Preparing the Talk

Figure out what you want to say first. The outline view in PowerPoint and Keynote is a great way to organize what you want to say without worrying about how it looks.

Determine a small number of things that you think are key items that you want the audience to walk away with. Mention them at the start, summarize them at the end.

The classic advice is not to put too much text on your slides, and avoid reading the text directly. A pragmatic way to manage this is to set your body text font pretty large (I use 44 point fonts for my body text if I can get away with it), and break up any slide that threatens to overrun.

That said, you can make the opposite mistake as well -- I find it tiring to go to a talk where all the slides are two-words and a non-sequitur picture. People may be viewing just your slides online, they need a little bit of context. Even people in the room often need a bit of context on the slides to help follow what you are saying.

Building up the slides during the talk point by point using animation can be a good way to keep from reading too much text on the slides. And it can help time a "punch line" by keeping it from the audience until you are ready. But don't use it everywhere. (I've always wanted to give a talk that used bullet points like Colbert does in The Word segment, as ironic commentary. But that's very hard, and I'm not sure it would work.)

I do like to separate off major sections of the talk with title-only slides. I've started tying these sections together by putting images on the title slide, and carrying those images in the background of the slides in the section at something like 20% opaque. It makes it easier for people in the audience to follow along.

Keep the number of moving parts to a minimum -- rather than switch to an editor to show code, copy the code into your slides. TextMate has a "Copy to RTF" bundle that preserves syntax highlighting, or take a screen shot.

Similarly, try to avoid having to run code during your talk. (Unless the interactivity is the point, as in a longer workshop).

Try not to depend on Internet access for a demo, you never know how flakey the Internet is going to be at a venue. At the very least, have a bunch of screenshots in hand as a plan B.

Practice. Do a dry run by yourself. If you see something wrong in your slides or missing in your talk, write it down. But do try and get a clean dry run at some point, so you get a sense of how long the talk is.

If possible, practice in front of other people. Nearly every talk that somebody at Pathfinder gives has a practice run as a company brown bag. This is invaluable feedback as to what is interesting in your talk and what is not.

In many situations, your last slide will be up for a while while you answer questions or something. Put something useful on there, generally either a summary or places to go for more information.

Doing the Talk

Make sure you bring everything you need. Laptop. Power Cord. Monitor Adapter. Remote Control. Don't assume that anything will be as you expect in the actual setup. As I type this I'm going to put my monitor adapter in my backpack. Put a copy of your talk on a thumb drive. Put a copy online using Dropbox or Gmail it to yourself.

If at all possible, scope out the space well before your talk. Where will you stand? Will you be able to see your own slides? Will you need a remote, or will you need to stand in front of your presentation machine?

Try and set up early if you can (if you are part of a conference program, you're limited because there's a previous speaker). Still, the less the audience sees you fumbling with cables the better off you are. It helps if you can check to see if the display resolution matches your slides.

Before the talk, shut down as many programs as you can on your laptop. Especially shut down notifiers -- you don't want an IM from your mom popping up in the middle.

I use a Mac utility called Caffeine to keep my computer from going to sleep in the middle of the talk, because it's annoying when that happens.

The point of all this is to reduce the amount of things that can go wrong so that you can be as relaxed and have fun during the talk.

Getting started can be awkward. Sometimes it helps to get the audience involved by asking a question or two right off the bat -- this can also help you gauge how much the audience already knows about your topic. It can also be an unobtrusive way to make sure that everybody can hear you.

At the end, if there's time, take questions. Get in the habit of repeating the question before you answer it. There's a good chance that most of the audience didn't hear the question. If you are miked and being recorded, the recording probably won't pick up the question unless you repeat it.

Stick around afterword if you can, often there will be one or two more people who have questions.

Related posts:

1. Artifacts of a Presentation
2. Ruby Code Audit Checklist
3. Windy City Rails

We have an internal application that does staffing, time entry, and now Paid Time Off (PTO) accrual, scheduling and management. It is quite nice, as it has replaced three existing systems, and replaced a number of manual, tedious tasks. I started it last year, as our current system was very inefficient. It was a simple Ruby on Rails app that I was able to get working in a few weeks. Over time the functionality grew.

We recently added in PTO accrual and functionality to debit PTO time. In doing so in a test driven manner was great, as we could put all the edge cases. What we found was that many of the requirements were plentiful with edge cases. For instance, we get paid on the 15th or end of the month, unless that is a weekend. Then we get paid on a Friday - Except if that Friday is a holiday, then the previous Thursday - Except - if that is also a holiday.... So it is really the previous non-weekend, non-holiday on or before the 15th or end of the month. The same holds true to determine the beginning of the billing period. If the Monday is the 2nd, than for some operations the effective billing period start is Tuesday the third.... Ugh...

Our initial thoughts were filled with visions of lots of very similar tests for all contexts that do things depending on the start or end of a billing period. We didn't want to have lots of duplicate test code to test all edge cases, so we decided to extend the Date object to have a few helper methods to do the complicated logic in one place. We get the full range of the billing period start and end, and then trim off any holidays or weekends. What this did, was allow us to test the complicated logic in unit tests with a full set of complicated edge cases. We created many crazy examples of billing periods starting and ending on weekends, holidays, and holidays before and after weekends. This created a very robust set of methods to be used anywhere in the system.

We then mocked a call to each Date helper method everywhere in the system where it cared about what day it was, and weather it was the start/end of a billing period. We had only a few edge cases now: is it the true effective billing period start/end, or not. Our tests could then focus on the guts of what it actually did, regardless of the effective date.

This demonstrates how powerful unit testing is, and how mocking can really keep your tests concise. It made not only our code cleaner, but our tests cleaner. It reduced duplicate code, and increased our assurance that the code will function as designed.

That being said, it still doesn't change the fact that implementing HR logic in any language is a pain in the ass. I have worked on a couple of systems for accounting departments in the past, and their business requirements are much worse than HR. Dealing with job codes, general ledger accounts, etc can make your head spin. All I know, is that without TDD, this system would be buggy.

Related posts:

1. The Testing Interviews
2. Ajax and Leaky Business Logic
3. The Hazards of Exposing Business Logic on the Client

It's time to play "Ask A Tester Person", where I answer questions that I've gotten via email or otherwise about Rails Testing topics.

If you have a question for Ask A Tester Person, send it to railsprescriptions at gmail.com.

I've got two questions today:

Question 1: I'm writing too many tests!

One subject I still have questions
about is how to test authorization in controller tests. In my
applications I've been testing three different user cases for every
controller action, but this leads to, for example:

test_edit_by_anonymous_user
test_edit_by_unauthorized_user
test_edit_by_authorized_user

So every action has at least three tests, which obviously means a
*ton* of tests for the entire application. This has always felt like
overdoing it but I haven't yet been able to convince myself that just
testing the authorization part of the code is sufficient. If I could
isolate the authorization mechanism for testing that might convince
me, but I'm not really able to do that (maybe my authorization process
needs to be redesigned?), and I'm not sure I'd be convinced
anyway...how the application responds in all three cases seems like
something that *should* be tested for every action...

I doubt that your authorization process needs to be redesigned, but then I've never seen your authentication process.

I'd recommend a couple of different things to clean this up a bit. On the assumption that unauthorized access has largely the same behavior across the application, you can create a boilerplate test like this example -- the example uses Shoulda, but the basic idea should work in any framework.

  self.def should_block_access_for_anonymous_user(*actions)
    actions.each do |action|
      should "block anonymous access for #{action}" do
        logout_current_user
        get action
        assert_redirected_to root_path
      end
    end
	end

Which you would then use as:

  should_block_access_for_anonymous_user :edit, :update, :delete

The implementation shown here is probably a little too simplistic for full use (you might need to pass more information than just the action for each request), but the simple version could easily cover the most basic authentication issues with very little fuss.

If your authentication system is more complicated, the other option is nested contexts -- again, this is in Shoulda, but can be adapted to RSpec or the Context gem:

context "GET edit" do

  setup do
    # generic edit setup here
  end

  context "with an anonymous user" do
    setup do
      logout
      get edit
    end

    should "not allow access" do
      assert_redirected_to root_path
    end
  end

  context "with an admin user" do
    setup do
      login_as_admin
      get edit
    end

    should "allow access" do
      assert_response :success
    end
  end

end

The upside of this compared with what you are probably doing is that it consolidate the setup between the different options. The downside is that it can be kind of verbose and hard to follow. But it's still potentially easier than writing three separate tests for each action.

Question two: I'm creating too many objects!

Okay, I actually can't find the email that this came from, which is driving me crazy, because how do you lose an email message these days? Anyway, the gist was that this person's tests were running very slowly because he or she was creating so many objects for each test -- I distinctly remember the number 50 to 100 being tossed around. So the question was how to avoid creating so many objects?

The bottom line is that there's no way that you should need to create 50 to 100 objects for every TDD test, or even for any TDD test -- it's pretty rare that a unit-level test really needs that much data to work. There are a lot of potential issues here. Three that spring to mind are:

• You are trying to test too much code at one time. It's possible (though still not very likely) that an integration test might need that many objects, but testing a single method almost never does
• You've transitioned from fixtures to factories, but you are still writing your tests as though you were using fixtures.
• You have perhaps an unnecessary fixation on providing "realistic" data in unit tests.

There's some overlap here. One cause of this is problem is that in fixtureland, there's very little marginal cost to creating new objects, so the tendency is to create fairly large aggregations of objects that cover all possibilities and have that be the universe for all the tests. When you transition to factories, though, keeping that big data blob around is not necessary. Since you can and should be custom-creating the data for each unit test, most model methods only need one model with specific attributes in order to specify the logic. Sometimes that model will need associated objects, but the factory tool can be set to create those automatically.

A special find method or named scope can be tested with as little as two objects -- one to be found and one to be skipped. Sort logic similarly can be tested with two or maybe three objects. If the logic is really complicated, it's better to do multiple tests with small amounts of data than one test with the whole shebang. The idea of a "unit" test is to verify one small piece of logic with as little data as possible, not to check program behavior under realistic data load -- that's what integration tests, performance tests, and actual user acceptance is for.

I feel like I'm answering the question "How do I create fewer objects in my tests?" with "By creating fewer objects in your tests", I hope this answer gives you some tools for minimizing the number of objects you need to create in your tests.

Related Services: Ruby on Rails Development, Custom Software Development, Testing and Quality Assurance

Related posts:

1. Elements of Testing Style
2. Rails Testing Frequently Asked Questions — The Non-Code Version
3. Rails Test Prescriptions is now on sale

Quite a while ago, I wrote a blog post which included some code which allowed you to use ActiveRecord without needing a database table.

I recently needed that functionality again, so I converted that code into a plugin and put it on github so that I could easily include it in another project. While doing this, I also cleaned up and simplified the code quite a bit.

The github page is here: http://github.com/AnthonyCaliendo/acts_without_database/

Related Services: Ruby on Rails Development
, Custom Software Development

Related posts:

1. TankEngine: New plugin for Rails iPhone Development
2. acts_without_database: Leverage ActiveRecord with Non-Database Backed Objects
3. Rails Development for iPhone with rails_iui

Eric Smith from 8th light gave a hands-on TDD presentation at last night's Chiphone meeting, hosted at Obtiva's downtown office, (conveniently located near the the train).

There was a good crowd of people, most attendees have 'played around' with iphone development, 4 have actively developed apps (3 people have live apps in the store).  From my quick survey of those that have submitted apps, it seems most of them were free utility apps or simple games, with at least one commercial app Dash for Confluence. It also seemed that no one had yet needed to do any animation beyond the basics, with just a bit of core-animation, but no need for more lower-level openGL or animation engines.

Eric started off by saying that he's given talks on iPhone testing, but that just telling people what to do is not the same as letting them experience it for themselves,  so we did a Randori, where a pair starts working on some code, and every 3 minutes one person from the pair swaps out and chooses his replacement from the crowd.

What I liked about this was that I felt like I got to know the audience better, and actually watch people reason their way through the code or a testing/mocking issue.  (You know how sometimes you go to a user group, and it can be hard to get a chance to talk to others, or sometimes there is a 'know-it-all' guy, and you just want him to shut up. Knowing that you are going to have to go up there and code is a great way to silence those types)

When it was my turn,  there was an interesting issue with one of the tests that had us all stumped for a bit, but ultimately ended up being one of those problems where you need to deconstruct everything and build it back up. (The issue was that while we were trying to set fooController.textView.text = @"foobar", we hadn't instantiated a textView object, or set it on the controller yet.)

We got into some testing, mocking strategies, and a few Xcode tips & tricks, but not being all that familiar with the mocking framework, it would have been nice to just do a little intro on the api, but whenever someone was stumped the answer was shouted out pretty quickly.

It was nice to get some pizza, so a big thanks to Obtiva & 8thlight for putting this together. I wish we could do some presentations here at Pathfinder, but our space is better for a meet & greet, than a presentation. (plus I don't think as many people would come to the River North area)

I was new to a Randori, and I think this style of presentation is good, but I do have a few ideas I think I'll include when I host one:

1. Set out a basic agenda, introducing the approach, the codebase, relevant api, and where we're hoping to end up
2. Moderate the work (and the crowd), and be ready to help out in case the pair gets stuck (which means you really have to keep an eye on what they are doing)
3. Make the work meaninful, and the outcome tangible. (we were able to see our posts getting pushed to twitter, which was nice)
4. Push the final code up to github as a branch, so they can check it out later and compare the original to what they created as a group

There were a few times when I couldn't quite hear what the pair was saying, or read the screen that well, and though it wasn't a large group there were a few side conversations that made it harder for me to follow. I think this was most likely to happen when the pair was struggling, so a little moderation would probably keep things moving along fast enough to keep everyone engaged. I saw another post that also laid out some strategies for how to best host a Randori session.

I'm looking forward to the next chiphone meeting, and I think there was some talk of doing a group project to make a little app for next month's WindyCityRails.org conference.

Related Services: iPhone Application Development,
Ruby on Rails Development, Custom Software Development

Related posts:

1. ChicagoRuby meeting ‘Test Prescriptions’ recap
2. Book Review: Core Animation for Mac OS X and the iPhone
3. Chicago JavaScript Meetup Group draws a big audience with varied skill levels

To make a cheap joke and paraphrase a common quote, web developers and web designers are two groups separated by common languages. In our case, the languages are HTML and CSS, which are the output of both the web design process and the web development process. Developers and designers produce their HTML/CSS in different ways and with different goals. Here are some ideas for bridging the gap so that the developers and designers on your team can work together smoothly.

Designers and developers obviously have different goals for their HTML -- developers have issues of reducing duplication, organization, and performance that are largely not the designer's concerns. The designer is primarily concerned with how the HTML looks and behaves to the user.

By the way, I'm absolutely not trying to make this some kind of left brain/right brain thing. It's more of a software needs vs. domain expertise thing. Once upon a time, I was writing scripts that outputted router configuration files, and I had exactly the same issues with the router domain experts -- my software engineering desire to structure the code without duplication conflicted with the way the router experts liked to structure their hand-written configuration instructions.

Our teams have had success with getting everybody on the team using common tools as much as possible. This means putting designs and code in the same code repository, and it means the development team supports the designers in creating a set up to run the current development version of the app locally. (By the way, this article by Mindy Wagner might be helpful if you are trying to convert everybody to Git.)

From the developer perspective, if you are working with HTML provided by designers, it's important to keep the view layer of your code accessible to the HTML providers. Exactly what this means is subject to negotiation. Left to my own devices, I'd be putting all kinds of HTML generation in Ruby via helpers or something more esoteric. That didn't work out well when the designer needed to go mucking about in metaprogrammed Ruby code to start changing CSS classes. We do better with putting pure logical stuff in helpers and using partials to split view logic. I'm pretty sure that if I were to suggest Haml for a project, the designers would veto it -- Haml barely meshes with the way I think of HTML, the designers I've shown it to have basically recoiled in horror.

That said, everybody likes Less CSS, which seems to augment CSS in ways that seem very intuitive to CSS designers, and which are very satisfying to coders. It does all the things that you would expect CSS to do if it was a real language, but vanilla CSS works just fine. It really caught on quickly here.

From the designer perspective, get everything out of photoshop and into HTML/CSS as early as possible. It's just too easy to put stuff into a photoshop image that represents hours of development work, leaving the developers in the position of trying to determine which parts of the impossible image are vital, and which are just chrome. Doing the wireframes in HTML/CSS keeps the design honest.

We use this little hack to integrate wireframes into the development app, which is really nice for developers when working with in-progress designs.

Ultimately what it comes down to is for everybody in the team to take some responsibility for making the team work together. The developers need to make the code base accessible to designers and to be alert to basic design issues and flexible in adapting wireframes into the site. Designers need to help place their deliverables in a format that keeps the developer from having to guess how things are supposed to work -- nobody wants that.

Related Services: Ruby on Rails Development, User Experience Design, Ajax Rich Internet Applications

Related posts:

1. A New Workflow for Web Designers
2. Down with HTML + Code Markup!
3. Designers on Joel

Mocha is the mocking library used by the Rails team, so it has understandably gained some traction among Rails developers. I have started using it over flexmock lately, but ran into some problems with partial mocks on ActiveRecord objects. The problem stemmed from the fact that ActiveRecord instantiates new records when returning records from finders, which meant that creating partial mocks for a particular record was difficult.

I created a helper method to make this easier, and so far it has cleaned up a bit of my tests.

Using #any_instance is not helpful in the cases I ran into, since I wanted to target a specific record for different expectations.

You could mock out the individual #find or #find_by_* methods as needed in each test, but that didn't seem ideal to me. Instead, I dug a bit into ActiveRecord to find what method was called when it actually instantiated the records after a find. I discovered that there is an #instantiate method which takes a hash of column=>value pairs from the finder to instantiate those records.

The following is the helper method which I created to do this:

 
def mock_active_records(*records)
    records.each do |record|
      record.class.stubs(:instantiate).with(
        has_entry('id', record.id.to_s)
      ).returns(record)
      record.stubs(:reload).returns(record)
    end
  end
 

Here is an example test:

 
require 'test_helper'
class UserTest < ActiveSupport::TestCase
  setup do
    @user = User.create!
    @non_pending_order = user.orders.create!
    @pending_order = user.orders.create! :pending => true
    mock_active_records @non_pending_order, @pending_order
  end
 
  test 'cancels pending orders when deactivating user' do
    @non_pending_order.expects(:cancel).never
    @pending_order.expects(:cancel).once
 
    @user.deactivate!
  end
end
 

This test makes sure that when I deactivate a user, that I call the cancel method on only the pending order.

Now, you may be asking "why don't I just test the side effects of cancel on the orders?" Well, I feel that what happens during cancel for an order is outside the scope of a unit test for user. In this example, cancel can have a multitude of side effects. In the context of a unit test for a user, I don't care what happens when I cancel an order. I only care that I do cancel it.
Also, if cancel needed to make an outbound call to another system, I wouldn't want an external system to be a dependency of my unit test. Mocking out the method removes any external and implementation dependencies in my unit tests (a functional test is a different matter, mind you).

Related Services: Ruby on Rails Development, Custom Software Development

Related posts:

1. How to use will_paginate with non-ActiveRecord collection/array
2. activerecord tests: modify activerecord logging without tripping rollback convenience
3. Using ActiveRecord and Metaprogramming to Define Constants for Enumerated Types

So, I tried Blue Ridge for the first time yesterday and I thought I'd write down some quick impressions. Hence, Rails Testing First Look.

Disclaimer: We came into this tool so cold our toes froze. We fumbled, we made mistakes, we probably missed really great ways of doing things. I look forward to being enlightened.

Let's do this question-and-answer style: What is Blue Ridge? Glad you asked. It's an framework for testing JavaScript from inside a Rails application. For the most part, it's a cohesive bundle of existing JavaScript test tools, such as Screw.Unit. The value-add of Blue Ridge is an easy installation and nice integration with Rails testing tasks.

Why did we start using it? We had some simple JavaScript stuff to do, and thought it would be a good time to start out with what looks like a solid way to test.

Is it easy to install? Very. Install as a plugin ./script/plugin install git://github.com/relevance/blue-ridge.git, then generate the Blue Ridge files with script/generate blue_ridge.

Blue Ridge will install a test/javascript directory. In that directory will be a sample test file application_spec.js, a helper file, and a fixture directory. Each javascript test file is assumed to have a matching HTML file in the fixture directory which is loaded to provide a sample DOM for test purposes.

Does it make any other assumptions? BlueRidge assumes you are using jQuery as your library. It's theoretically possible to use Prototype, but we ran into continual difficulties (possibly because we were doing it wrong), and actually wound up switching to jQuery for the project, easy enough to do since we just started.

How do you write tests? Tests are written using Screw.Unit syntax, and if you are familiar with RSpec, the syntax will look pretty similar. Here's the final draft of the first couple of tests we wrote, for a search box with default text that goes away when focused. The TextMate Screw.Unit bundle was very helpful, but other than that, the tests are pretty straightforward.

Screw.Unit(function() {
  describe("With my search box and default", function() {
    it("should switch the default", function() {
      search_focus($('#unified_search'));
      expect($('#unified_search').attr('value')).to(equal, '');
    });

    it("should switch a non-default", function() {
      $('#unified_search').addClass('search_entry');
      search_blur($('#unified_search'));
      expect($('#unified_search').attr('value')).to(equal, default_text);
    });

    it("should not switch if there is a value", function() {
      $('#unified_search').attr('value', 'Fred');
      search_blur($('#unified_search'));
      expect($('#unified_search').attr('value')).to(equal, 'Fred');
    });

  });
});

How do you run tests? Two ways. Blue Ridge provides a test:javascripts Rake task that will run all your Javascript tests in the terminal, this is also suitable for including in your continuous integration build, for example. A very nice feature from Screw.Unit is the ability to run tests in browser by simply opening the fixture HTML file in the browser of your choice. As long as your choice isn't Safari, which isn't supported at the moment. The ability to run the tests in console and in browser is very useful.

Any gotchas? Oy. We had what appeared to be some minor differences between the Rhino implementation that powers the console tests and the browser tests, leading to tests passing in the browser and failing in the console. We weren't quite able to do what amounted to integration tests -- we tried to trigger the JavaScript events so that the jQuery functions tested above were triggered, but couldn't get that to work. You have to be careful that the fixture HTML file actually has all the DOM elements you need, and remember that fixing the actual view doesn't change the fixture. Screw.Unit's error messages on failure aren't as helpful as they might be, there also seemed to be a thing where the fixture DOM wasn't actually being reset between tests, but I'm not 100% sure about that, we wound up working around it.

And in the end? That said, I did feel better about my JavaScript after having tested it. Fixing the JavaScript code, it was nice to see that other functions hadn't broken. There's a lot to like here, and I'm hoping to get past my initial problems to a tool that will improve the JavaScript parts of my code.

Related Services: Ruby on Rails Development, Custom Software Development

Related posts:

1. Rails Testing Frequently Asked Questions — The Non-Code Version
2. Rails Test Prescriptions is now on sale
3. Getting Started With Rails Testing Guide Now Available

Rails Test Prescriptions, the eBook put out by Noel Rappin, Director of Rails Development at Pathfinder, has been picked up by Pragmatic.

Congratulations to Noel - he's done a great job of furthering testing best practices in rails, and this is a great reward. As he said "I’m very excited by this. I’ve wanted to work with Pragmatic for as long as they’ve been publishing books, and I’m thrilled that this particular project will be able to get wider distribution and access to Pragmatic’s editorial expertise and skill."

* The current free “Getting Started with Rails Testing” ebook will continue to be available. If, at some time in the future, there’s a better Getting Started tutorial in the Pragmatic book, it may be offered as a replacement.

* The update site for current Rails Test Prescription owners will continue to be available for the foreseeable future.

* There will be one more official update to the current Rails Test Prescriptions, probably around the end of August. This will wrap up the chapter or two I’m working on, and tie up some other loose ends.

* After that, errata and information about changes to test tools will most likely be handled via this blog and an errata page on the rails test prescriptions site.

This is Noel's 4th book with a major publisher, following Professional Ruby on Rails, wxPython in Action and Jython Essentials. We're happy for Noel and happy to have him at Pathfinder.

Related Services: Ruby on Rails Development, Custom Software Development

Related posts:

1. More Kudos for Rails Prescriptions
2. Rails Test Prescriptions is now on sale
3. Announcing Rails Prescriptions

I have come to the conclusion that doing rails development native in windows is not worth the cost. Things may seem to run smooth initially, but over time problems inevitably come up, and they have become enough of a pain point that i'm moving to a linux virtualization. This for me makes particular sense as most of the full time ruby guys in my shop are using macs and are no help when it comes to figuring out windows only issues.

The first lesson usually learned by rails developers using windows is to use cygwin.  I didn't initially, until i need to use capistrano for deployment, and guess what, windows doesn't support ssh from the command line, so time for a second rails installation using cygwin for this support. In general, dealing with any type of issue is more frustrating when using windows because most help on the web is not windows focused. A common disclaimer seen when searching boards for help with RoR issues on windows is, "Well, I'm not that familiar with installing xxx on Windows, but" . It's just going to be much easier to install, say gems for instance, if you can build them in the environment for which they were developed.  In fact, awkward native gem compatibility it probably the single biggest reason not to stay on windows.

Then there are issues that don't have to do with trying to fix something that's broken. Performance for one. As seen here, certain tasks on windows are much slower than if virtualized, even if the virtualization has inferior resources.  Also, developing on windows makes for a poor example when it comes to deployment and dealing with production issues as Rails apps are rarely run on windows.  If you're not used to a linux OS, you're going to be completely useless when it comes to working on these machines.

What it boils down to is that Rails and everything around Rails is targeted towards linux. The web services, heavy use of git, the framework itself.  Sure, becoming familiar with Linux with have its own set of frustrations and headaches, but those will be useful lessons that will bring you closer to Rails and its community, rather than farther away.  So until i get my mac and can virtualize my windows enviroment (um, hello Dietrich),  rails is going virtual.

Related Services: Ruby on Rails Development, Custom Software Development

Related posts:

1. Ruby on Rails with Windows – How I made it work
2. TankEngine: New plugin for Rails iPhone Development
3. Rails Development for iPhone with rails_iui

I'm writing a functional test:

should "do something functional"
  get :search,  rder_id => @order.id, :user_id => @user.id
  # and so on
end

The get call in that test simulates a browser request. Intuitively, you would (well, I would) expect this request to be identical to a request coming from the actual view, via a helper like link_to("search", :action => :search, rder_id => @order.id, :user_id => @user.id). At least, you'd expect that parameters hash in the controller to be the same between the

Makes sense, right? The testing call should set up the same environment as the actual call being tested.Well, if you've gotten this far, read the title that said "Annoyances", or have ever read any blogs, you know that isn't how Rails works. Specifically, the actual browser call has all its arguments converted to strings as part of going through the HTTP wire, but Rails, oddly, does not similarly convert the arguments in the test.

Most of the time it makes no difference -- if you pass the string or the integer directly to an ActiveRecord find method, everything works swimmingly. If you do a direct equality check on the parameter, though, you can get code that passes tests, but fails in the browser because the string value is no longer equal to the integer value.

For some time, I've had this on my list of annoyances that I don't have the energy to fix, right next to the slightly misaligned light over my desk, and the fact that they bought the wrong kind of Kleenex at the office that one time.

This week, Adam Milligan at Pivotal Labs tried to do something about it. Specifically, he created a Rails patch, then a plugin, that can raise a warning or an error when a non-string argument is passed to an HTTP method in a functional test.

Adam chose to fail or warn rather than silently convert the parameter because he feels that some arguments that might get placed in an HTTP method don't have clear correct conversions (his example is false), and he's trying to avoid setting up a whole different kind of difficult-to-diagnose test to app misalignments.

As much as I love that Adam did this, I kind of think that it's more consistent with Rails design to silently convert, to make the browser call and the test consistent. Still, having the code warn or fail (your choice) is a pretty good way to get into good habits and avoid having to track down weird test errors. So, thanks, Adam.

Related Services: Ruby on Rails Development, Custom Software Development

Related posts:

1. Rails, Ajax, RJS, and Testing
2. Rails Testing First Look: Blue Ridge
3. Elements of Testing Style

Dot, dot, dot, dot, dot -- tests are passing, looks like it's time for lunch -- dot, dot, dot, dot, F. F? F? But the code works. I know it does. I think it does. Why is my test failing?

One of the most frustrating times as a TDD developer is that moment when a test is failing and you don't know why, as opposed to the more normal case where the test fails as expected. Here's a grab bag of tips, tricks, hints, and thoughts to get us all through that difficult time.

Something Must Have Changed

This may be the most obvious piece of advice in the history of ever, but I find it's worth repeating, mantra-like, when confronted with a bad bug:

When a formerly-passing test fails, it means something changed.

It may be in the code, or the system, or the test. But it's probably not sunspots, and it's probably not evil spirits possessing your MacBook. (Unless you are either living in a Charles Stross novel or writing Perl, but I digress...)

Looking through recent changes can help figure out what the cause of the failure is. Git's bisect tool can do this automatically, or you can just look through recent changes in your source control viewer of choice. If the test was passing at one time, there's a good chance the answer is in there somewhere.

This is a great argument in favor of committing to your source control very, very frequently (especially when you are using git and can do local commits), so that your changes are very granular.

Isolate

When looking at a small number of failing tests, it's helpful to be able to run just those tests. Autotest is outstanding for this, since it will run the failing tests over and over until they pass. This is especially helpful if you have a number of failing tests that are not in the same test class.

This little code and terminal snippet is very helpful for quickly running one class at a time, which is almost like isolating a failing test, or at least close enough to be useful. Depending on your IDE and test framework of choice, you may also be able to run individual tests from the IDE.

Isolating tests makes the tests run faster when you are focused on just a few tests, and also makes any diagnostics you insert easier to interpret.

Two tips that I've stolen from listening to and reading Kent Beck:

• Back out your entire most recent change since your last passing test and start over. This works best if you work in very small increments, but it gets you out of the "I know I typed something wrong but I just can't see it" nightmare
• Replace all the expressions in the method under test with literals -- if that passes, then put the expressions back one by one until you find the culprit.

Diagnose

I have to say, I'm not a big fan of using stop-and-step debuggers. I've used them when I've been in an IDE, I've never really used the Rails command line debugger, but mostly I've found that not to be a great experience.

Normally, to diagnose what's going on in a test, I usually either add additional assertions in the test or have the code print information to the console. If I diagnose via assertions, generally I'm testing the values of variables in more detail.

For some reason, I see a lot of people using Ruby's puts method to write to the console -- I recommend p, which calls inspect on the object before printing, and generally results in more informative output. As a matter of course, I put require pp, which allows me to use pp to get pretty-printed output, which is nice for nested data structures. Also, y gives a YAML representation of the output -- very readable for ActiveRecord objects.

>> x = {1 => ['a', 'b'], 2 => 'c'}
>> puts x
1ab2c

>> p x
{1=>["a", "b"], 2=>"c"}

>> pp x
{1=>["a", "b"], 2=>"c"}

>> y x
---
1:
- a
- b
2: c

Especially if I have autotest running just the one test, I've been known to bury print statements all over the place -- controllers, Rails itself (often educational). Just remember to take them out when you are done.

Clear Your Head

Take a walk. Force your pair to solve the problem. Get a cup of coffee (actually, I hate coffee, get a Diet Coke). Take a nap. All those silly clear your head things really do work sometimes.

Band Aids

It's tempting sometimes to comment out the offending test and then your suite passes and all is well with the world again. That's generally a bad idea (although sometimes a major refactoring can genuinely make tests obsolete.

Hope this helps. What do you do to fix stubborn tests?

Related Services: Ruby on Rails Development, Custom Software Development

Related posts:

1. Rails Test Prescriptions is now on sale
2. Lesser Known Test Processes
3. Again With The Test Driven Development

What with upward of two people saying nice things about last week’s post, I’ve decided to keep going with part two of a look at some real testing code.

Most code-heavy tutorials show the code but not the tests — I’m doing the opposite here, and showing the tests, but not much of the code. Also, although I’m presenting these tests in chunks, you should realize that there was a lot of back-and-forth from Cucumber to tests to code and some backtracking, most of which I’ll spare you from having to wade through.

At the end of last week, I had run through the tests for spam-prevention code which worked by limiting the rate at which a user could send messages to other users of a particular social networking site. Cucumber was involved, and I think I went off on a tangent about writing lots of tests.

Once the basic rate limiting code was in place, the client and I came up with a couple of special cases. The application allows a user to explicitly reply to a specific message sent to them. We agreed that these replies should not count towards the rate limit on the grounds that a reply was, pretty much by definition, not spam. Similarly, we decided that any message between users with a friend relationship on the site also doesn’t count toward the rate limit. More subtly, we decided that if a user was inadvertently blocked, then reinstated by an administrator, that their rate count should drop back to zero, so the user doesn’t just get immediately re-blocked.

The Cucumber tests:

Scenario: Reply behavior
  Given I am a user who is not a new member
  When I send 4 messages in a day
  And I reply to a message
  And I send 1 message in a day
  Then 6 messages are sent
  And I am not blocked from sending further messages
  And the administrator does not get an email

Scenario: Friend Behavior
  Given I am a user who is not a new member
  When I send 4 messages in a day
  And I send a message to a friend
  And I send 1 message in a day
  Then 6 messages are sent
  And I am not blocked from sending further messages
  And the administrator does not get an email

Scenario: Unblocked behavior
  Given I am a user who is not a new member
  When I send 6 messages in a day
  Then I am blocked from sending further messages
  When I am unblocked by an administrator
  And I send 5 messages in a day
  Then 5 messages are sent
  And I am not blocked from sending further messages
  And the administrator does not get an email

These tests are quite similar in structure to the tests I started with last week. I might start thinking about combining some of the steps, but in Cucumber, I bias in favor of having the actual test be as clear and readable as I can get it. I don’t think these scenarios are so complicated that they require simplification.

Most of these steps have already been defined, here are a couple that aren’t. The first two steps are slight variants on the message sending step definition:

When /^I reply to a message$/ do
  original_message = Factory.create(:message, :sender => @recipient,
      :recipient => @sender)
  message = Factory.attributes_for(:message, :sender => @user)
  message[:in_reply_to] = original_message.id
  visit(messages_path,
      :post, {:recipient => @recipient.id, :message => message})
end

When /^I send a message to a friend$/ do
  @user.become_friends_with(@recipient)
  visit(messages_path,
      :post,
      {:recipient => @recipient.id,
          :message => Factory.attributes_for(:message, :sender => @user)})
end

One thing that you may have noticed about these step definitions. Despite all my jumping up and down about Cucumber being a black-box system, both of these steps bypass the UI to complete the setup. The first step creates a factory message and the second step creates a friend relationship. In both cases, the actual message send being tested passes through the UI.

There are basically two reasons for bypassing the UI in the setup. One is, of course, that it’s the setup and not the action being tested, the second is that being a purist all the time is a pain, and it’s much easier to get the background info out of the way directly.

The final missing step, however, is completely through the UI — the step logs the user out, logs in as an administrator, navigates to the page, unblocks the user, and then logs the administrator out and the original user back in.

When /^I am unblocked by an administrator$/ do
  @blocked = @user
  visit "/logout"
  Given "I am a logged in administrator"
  visit path_to("the admin messaging page")
  click_link("Unblock")
  @user = @blocked
  visit "/logout"
  Given "I am logged in"
  reset_mailer
end

A little on the Rube Goldberg side, perhaps, but it works.

With the Cucumber step definitions in place, the question becomes what tests and code need to be written to make these pass. For the first two scenarios that adjust the definition of what makes a message count toward the rate limit, the code change will be in the User and Message models. Since it’s a thin controller that defers to the models for data, there shouldn’t be any code change in the controller at all.

Now, that’s a much easier determination to make in hindsight than up front, and as it happens I did write controller tests for both of those scenarios, largely because they were so similar to the controller context chunks in last week’s post that it only took about five minutes to set them both up.

The real test action was in the user and message models. I added a database column for messages called counts_toward_spam. The idea is that this would be true for most messages, but false for replies, friend messages, or messages otherwise cleared by the admins. This requires some unit tests in the message class to support it. Again, I’m using Matchy here, and testing the boolean spam_message?, which is basically an alias for counts_toward_spam that I added for readability. In retrospect, adding the method was probably unnecessary.

context "spam count" do

  setup do
    @sender = Factory.create(:user)
    @recipient = Factory.create(:user)
  end

  should "give an ordinary message a spam count" do
    @message = Message.new_from_params(
        {:subject => "fred", :body => "body"}, @sender, @recipient)
    @message.sender_id.should == @sender.id
    @message.recipient_id.should == @recipient.id
    @message.should be_spam_message
  end

  should "not give an ordinary message a spam count if it is a reply" do
    @message = @message = Message.new_from_params(
        {:subject => "fred", :body => "body", :in_reply_to => 11},
        @sender, @recipient)
    @message.should be_reply
    @message.should_not be_spam_message
  end

  should "not make a message between mutual friends a spam count" do
    @sender.become_friends_with(@recipient)
    @message = Message.new_from_params(
        {:subject => "fred", :body => "body"}, @sender, @recipient)
    @message.should be_friend_message
    @message.should_not be_spam_message
  end
end

The message tests simply set up the different classes of message and verify that they are classified appropriately, they are pretty straightforward.

I also added a test to user to verify that the spam count was being used appropriately — this is part of the same context as last week’s user tests. The user has already sent four messages in the setup.

should "not count a reply message" do
  message = Factory.create(:message, :sender => @user,
      :created_at => 10.minutes.ago)
  message.in_reply_to = 3
  message.update_count_toward_spam
  message.save!
  @user.spam_message_count.should == 4
  @user.update_message_block_status.should be_nil
  @user.should be_able_to_send_messages
end

It’s interesting what you see when you go back over a chunk of code to explain it to other people. In this case what I notice is the update_count_toward_spam method, which is part of Message that unsets the count_toward_spam_ field if the message is a reply and is automatically called as part of the controller create message code. However, strictly speaking, it should be tested in the message class rather than here (although, the message controller tests would also exercise it).

That’s the bulk of the testing for those features — at the time, I didn’t think there were any other special cases.

The part about unblocking a user requires controller tests, because the unblock action needs to be written in the controller. I’m making it part of the message controller, although I know that RESTfully speaking it probably should be a separate resource — the legacy app is such a REST tangle that it’s not worth it.

The controller test context looks like this — the setup creates a blocked user and calls the unblock method.

context "GET unblock" do

  setup do
    ActionMailer::Base.deliveries.clear
    @recipient = Factory.create(:user)
    @user = Factory.create(:user,
      :message_sending_status => User::BLOCKED_STATUS)
    @user.should_not be_able_to_send_messages
    admin!
    get :unblock, :user_id => @user.id.to_s
    @user.reload
  end

  expect { @user.should be_able_to_send_messages }
  expect { assert_redirected_to :action => :admin }

  should "send email to unblocked user" do
    assert_sent_email do |email|
      email.to.first == @user.email &&
      email.from.first == "do_not_reply@singlestravelintl.com"
    end
  end
end

The assertion tests verify that the user can send messages again, and that the user gets an email from the system to that effect. The associated user model test validates that the user’s spam message count is reset back to zero, which was the specific point of this round of tests (in the actual application, there were other Cucumber scenarios supporting basic administrative behavior).

context "unblocking a user" do

  setup do
    Message.new_from_params(Factory.attributes_for(:message,
        :created_at => 10.minutes.ago), @user,
         Factory.create(:user)).save!
    @user.update_message_block_status.should == "blocked"
    @user.should_not be_able_to_send_messages
    @user.unblock_message_status
  end

  expect { @user.should be_able_to_send_messages }
  expect { @user.spam_message_count.should == 0 }

  should "reblock" do
    @user.block_message_status
    @user.should_not be_able_to_send_messages
  end

end

Anyway, the code that I wrote along side these tests to make them pass seemed to work fine, and we deployed to production.

Shortly thereafter, we got a bug report. I haven’t stressed it here, but new users were limited to a single message in their earliest time on the system. We heard from a new user who sent a message, received a reply, and then replied back to that message, only to find that he was blocked, even though the reply message shouldn’t count toward the rate limit.

Interesting. It’s one of those bugs that almost turns philosophical — exactly when in this process does a user become blocked? In the code that I originally wrote, a user was blocked as soon as he or she hit the rate limit, and before sending another message. In fact, the code should wait until the user tries to send that next message to consider that user blocked, because a user who is at the rate limit border should still be able to send replies and friend messages without being blocked.

So, bug. Since the bug involves multiple interactions, I started in Cucumber:

Scenario: New User Behavior on reply
  Given I am a new user
  When I send 1 message in a day
  And I reply to a message
  Then 2 messages are sent
  And I am not blocked from sending further messages

All those step definitions exist, but the last two steps fail without further work. I wasn’t initially sure whether the code change for this would wind up in the controller or not — as it happened, it turned out to be a minor controller change and minor model change but it took me a few tries to get it right.

Since I already had a decent controller harness for similar scenarios, it took almost no time to adapt to the new condition:

context "with a borderline new user and a reply" do

  setup do
    reply = Factory.create(:message, :recipient => @user,
        :sender => Factory.create(:user))
    flexmock(User).should_receive(:new_user?).and_return(true)
    flexmock(Message).should_receive(
        :toward_spam_in_last_24_hours).and_return(1)
    post :create, :recipient => @recipient.id,
        :message => Factory.attributes_for(:message, :sender => @user,
            :in_reply_to => reply.id.to_s)
    @user.reload
  end

  expect { @user.messages_sent.size.should == 1 }
  expect { @user.spam_message_count.should == 1 }
  expect { assigns(:message).should_not be_new_record }
  expect { @user.should_not be_message_sending_blocked }
  expect { assert_no_email_to_administrator }
end

I have to say, in retrospect, that I’m not 100% sold on the use of the mock package here — it’s a clear user of mocking to limit the test’s exposure to the model layer, but I’m not convinced it makes the test more clear or readable. This setup and tests is very similar to the other bundles of controller test and makes most of the same assertions.

The main change was in the user method, triggered by the following tests — one of which tests the positive sequence, one the negative — and yes, the setups probably should have been combined.

should "move a new user to blocked mode after first message" do
  Timecop.freeze(Date.today)
  new_user = Factory.create(:user, :created_at => 1.day.ago)
  m = Message.new_from_params(Factory.attributes_for(:message),
      new_user, Factory.create(:user))
  m.created_at = 2.hours.ago
  m.save!
  assert_equal(2.hours.ago, new_user.last_message_sent_time)
  assert_equal("blocked", new_user.update_message_block_status(true))
  assert new_user.message_sending_blocked?
end

should "allow a new user a second message that is a reply" do
  Timecop.freeze(Date.today)
  new_user = Factory.create(:user, :created_at => 1.day.ago)
  m = Message.new_from_params(Factory.attributes_for(:message),
      new_user, Factory.create(:user))
  m.created_at = 2.hours.ago
  m.save!
  assert_equal(2.hours.ago, new_user.last_message_sent_time)
  assert_nil new_user.update_message_block_status(false)
  assert !new_user.message_sending_blocked?
end

The key here — which would be easier to see if the setups were combined — is the next to last line where update_message_block_status is called. That’s the method called by the controller when a new message is sent, and the false argument means that the new message does not count toward the rate limit. So in the second test, the user can still send messages, while in the first test, the user does move to a blocked status.

Having the existing suite of tests around the controller and model behaviors was a big relief when fixing this bug — it’d be easy to make a fix for this issue that affected one of the other scenarios (I know because I made fixes that broke a lot of tests…). This was a case where the tests clearly made me more confident in the fix that I made.

Related Services: Ruby on Rails Development, Full Life Cycle Software Development

Related posts:

1. A Real Testing Example
2. Elements of Testing Style
3. The Testing Interviews