-
Get a monthly update on best practices for delivering successful software.
So we just went through this humongous (believe me!) effort of upgrading the technical platform for one of our existing Rails applications that was running Rails 2.1, Ruby 1.7 and Mongrel cluster. The goal was to upgrade to Rails 2.3, Enterprise Ruby 1.8.6 and Passenger. It all started out as well as you would think. Updating the Rails gem, Ruby version, installing/configuring Passenger and updating relevant gems was pretty quick and smooth. Some quick and dirty testing of the application did not reveal any major problems or issues. Great! You are thinking the upgrade is mostly done att this point before you move on to the tests in the application!
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.
Continue reading »
Topics: Ruby on Rails, Testing, Upgrade

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.
Topics: agile, Ruby on Rails

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 Continue reading »
Topics: Ruby on Rails
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.
Continue reading »
Topics: Ruby on Rails
edge case city: requirements and testing dates for HR business logic
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.

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:
Continue reading »
Topics: Ruby on Rails, tdd, Test Driven Development

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.
Topics: Ruby on Rails, uxd
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: Continue reading »
Topics: rails testing, Ruby on Rails, tdd

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
Topics: rails testing, Ruby on Rails, Test, Test Driven Development, Testing

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
Topics: rails, Ruby on Rails, Windows, windows development
Here's a minor thing that bugs me all the time.
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, . At least, you'd expect that parameters hash in the controller to be the same between the
rder_id => @order.id, :user_id => @user.id)
Makes sense, right? The testing call should set up the same environment as the actual call being tested. Continue reading »
Topics: rails testing, Ruby on Rails, tdd, Test Driven Development, Testing, wapcaplet
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.
Topics: Ruby on Rails, tdd, Test, Test Driven Development, Testing
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.

Pathfinder and Rapid Reporting just launched EmploymentChek, the first employment verification tool that captures employment information from individual employers as well as automated subscription services.
Employment income is usually the primary means for an individual to repay a personal loan. Industry analysts estimate that 64% of all mortgage fraud is income- or identity-related, and that 21% of borrower applications have employment misrepresentations.
EmploymentChek is an addition to Rapid Reporting's existing web portal developed in Ruby on Rails.
Working within Rapid Reporting’s existing Rails environment, Pathfinder’s team delivered this highly-robust, first-of-breed solution in just over four months. EmploymentChek enforces anti-fraud best practices, and delivers extremely detailed reports including: extended public records findings and risk flags, responses to each interview question, interviewer’s subjective impressions, and detailed logging of unsuccessful interview attempts.
During development of EmploymentChek, the mortgage industry went through a period of downturn, which shifted priorities for the application. Pathfinder’s use of the Agile development process, which allows on-the-fly prioritization and reimagination of scope and features, allowed us the flexibility to meet the client’s changing needs in a volatile economic climate.
In addition, EmploymentChek’s service-oriented architecture allows for data vendors to be easily swapped out. This modular framework maximizes flexibility and eliminates the need for retooling the application when switching vendors, which saves time and money.
Take a look at the case study for more details.
As sort-of promised in last week’s post, I’m going to work through a real-world test example, with an eye toward explaining how and why I tested the way I did. Hopefully, I’ll be able to do this at blog-post length. If not, well, there’s always next week.
This site, which was a legacy rescue, allows users to send messages to each other within the site without having to give away their other contact information. The problem is that nefarious spammer types were creating logins and immediately sending messages to large numbers of the user population, irritating them. After some deliberation, the client decided on a rate-limiting strategy, where a member could only send a certain number of messages in a day, and a new member could send even fewer messages a day. Messages above that point would require administrative action to unblock the user’s privileges.
Topics: rails testing, Ruby on Rails, Test Driven Development, Testing