Jake Scruggs

Recently I was on a project where a bunch of code had been written before we arrived. It was quite a struggle to get the application under test. After a number of months the team hit 50% and then we just stayed there. We had a hard time getting client developer buy-in on the push upward from 50%. I didn't really understand this attitude at first, but after talking with the devs, I realized that the tests were mostly a nuisance for them. They saw it like this: "If I have to gut a few pages, as part of a changing requirement, now I also have to spend a day fixing the stupid tests. And the tests never really catch any bugs, so what was the point? All the tests are doing is slowing me down." Since the coverage was low and many of the test writers were new to unit tests we didn't really have a lot of protection from bugs. But we also had a sizable suite to maintain. They were feeling all the pain of keeping a test suite running but seeing none of the benefits. ...

As a traveling consultant I've developed a pretty poor opinion of American cars. Sliding doors that won't close, unfathomable glove boxes, ugly/boring interiors, boring/ugly exteriors, crazy placements for the radio/ac/heating/trunk release buttons, plastic doors with tails of extra material hanging off poorly drilled holes... The other day I was sitting in a Chrysler 300 talking with one of our tech leads about how he really wishes the rental company hadn't upgraded him and would've much preferred a Hyundai Elantra -- a car that costs half as much as the 300. It's a bit depressing.

I spent the last week writing a log parser of all things. The web site I'm currently working on is the sign-up page for a large company so they are very concerned about how far the average joe gets into the process before they give up. If everybody bails on the address page, then perhaps it's too complicated or unresponsive or... something. Up till now we've been redesigning pages based on some data and a lot of guesswork so we thought it might be about time to get some serious data on every session every day. Now the first thing you learn about parsing rails logs is that they are designed to be human readable but not so much computer parsable. An Apache request is one line. A Rails request log has lots more info, but is multi-line. And since we run a lot of Mongrel instances at once, all these requests are interleaved, so sorting them out is an intense computation (we actually ran out of memory a few times before we did some optimization). Our first pass was mostly ...

In my last post I talked about using RSpec without Rails, but since just about all my Ruby programming involves Rails, I should probably get into how to specify Rails code. RSpec on Rails: Models So if you're new to RSpec and you want to get started quickly, head on over to rspec.rubyforge.org , get RSpec, Spec::Rails and then, after you've created a new Rails project and rspec-ed it (all detailed on the website) you can run: ruby script/generate rspec_scaffold person name:string phone_number:integer cash:decimal Which will get you a bunch of stuff to play with. Of you'll need to set up your database.yml and run rake db:migrate if you want thing to work. Fire up your favorite IDE and find the person_spec.rb and you should see something like: require File.dirname(__FILE__) + '/../spec_helper' describe Person do before(:each) do @person = Person.new end it "should be valid" do @person.should be_valid end end Not the world's mos...

I'm going to try and turn my recent presentation on RSpec into a series of blog posts -- This being the first. Before I get on with it I would like to thank the Houston Ruby and Rails Users Group for having me. They asked some pretty insightful questions and were generally a great audience. I'd also like to thank ThoughtWorks for paying for my flight, rental car, and lost billable hours so I could do this presentation. RSpec without Rails So in order to show you how RSpec works, I'm going to start with specifying a class that deals with string case like so: require File.dirname(__FILE__) + '/../spec_helper' require 'string_caser' describe StringCaser do it "should upcase a string" do caser = StringCaser.new("A String") caser.upcase.should == "A STRING" end end After requiring a spec_helper and the file I intend to spec, I set up a 'describe' block. Inside the block there is a single spec (or example) which is als...

Later this evening I'm giving a talk on RSpec at the Houston Ruby and Rails Group. In case somebody misses a link, I'm posting them here: RSpec's homepage: rspec.rubyforge.org RSpec Users Mailing list: rubyforge.org/mailman/listinfo/rspec-users David Chelimsky's Blog: blog.davidchelimsky.net If you install RSpec as a plugin to your Rails project, then look inside: vendor/plugin/rspec/examples for some nice spec examples Once you've got RSpec and RSpec on Rails installed in your project, running: ruby script/generate rspec_scaffold person name:string phone_number:integer cash:decimal from the base of your project will get you a bunch of generated specs to look at and play with.