I am a big RSpec fan. But occasionally, I work on projects that use test/spec. When I want output the spec documentation with RSpec, I just use rake spec:doc. With test/spec, I couldn’t find such a thing. So I made one and stuck it in lib/tasks/test_spec.rake

Rake::TestTask.new(:specdox) do |t|
  t.options = '--runner=specdox'
  t.libs << 'test'
  t.pattern = 'test/**/*_test.rb'
  t.verbose = true
end
Rake::Task[:specdox].comment = "Generate specdox."

Now I can use rake specdox to see all the wonderful spec documentation!

I presented on RSpec 1.1 tonight at the Dallas.rb. I don’t claim to be an expert, I just love my specs (and now stories).

Feel free to take a look at the slides.

So I came across Dan Manges Fixture Factory as a way to relieve myself of the pain of fixtures for testing. I don’t mind fixtures that much, but when I have to start setting up so many different combinations, it gets a little challenging. In reading through the comments I found that Scott Taylor had implemented it as a plugin. Now I get all that goodness for my specs.

The other day I wanted to play with some things using script/console, but was feeling too lazy to set up all of the data I was going to need to do what I wanted. Sure enough after looking at the documentation for fixture_replacement, I can use it there too:

  % script/console
  >> include FixtureReplacement
  >> cause = create_cause
  >> user = create_user
  >> cause.users << user 

It is really useful for easily setting up your test data in the spec (or test) that you are writing. Instead of having to go off to the fixture files and add new fixtures (and try to remember to set up all of the dependent fixtures that are needed), you can use new_xxx or create_xxx to get an object to test in a valid state with all its dependent data.

Take a look at the FixtureReplacement plugin now.

I recently upgraded StagingTracks.com to use Rails 2.0. I was excited about so many of the newest features that it seemed the logical thing to do. I even decided to upgrade RSpec in the process so I would be able to play with some of the new features there too.

Unfortunately, despite extensive local spec’ing, when I deployed the app to Dreamhost, things did not go as planned. I was using piston to manage my Rails in the app and all of my plugins, so I didn’t need to worry about which gems were installed on the server. What I found was that when users tried to submit new information using the forms on the site, nothing would happen. Let me correct that: It would look like something happened, but no data was submitted.

So what was the problem?

I first started by watching the production.log to see if the data was even getting submitted. As expected, nothing was coming through. I then used the Tamper Data plugin for Firefox to see if I if the data was getting out of the browser. It was, but something interesting appeared. I saw a 301 Redirect when the page was submitted. Odd. Especially since the application wasn’t seeing the data and there were no redirects in the production.log.

So I started looking in the http access.log to see why the data wasn’t coming through to the app. What I saw was surprising:

- - [16/Dec/2007:19:24:30 -0800] "POST /shops HTTP/1.1" 301 591 "http://www.stagingtracks.com/shops/new" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"
- - [16/Dec/2007:19:24:30 -0800] "GET /shops/ HTTP/1.1" 200 319 "http://www.stagingtracks.com/shops/new" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

It looked like the POST (which goes to the ‘create’ method using Rails RESTful approach) was being redirected to ‘/shops/’. The browser would then call ‘/shops/ ‘ with a GET (which is the ‘index’ action). And the form submission never got through. Now I was perplexed. Why would the web server being sending the 301 Redirect?

It became a little clearer when I saw this in the logs as well:

- - [16/Dec/2007:19:15:11 -0800] "GET /shops HTTP/1.1" 301 591 "http://www.stagingtracks.com/" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"
- - [16/Dec/2007:19:15:11 -0800] "GET /shops/ HTTP/1.1" 200 89174 "http://www.stagingtracks.com/" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

For some reason, the web server was causing 301 Redirects when the trailing slash was missing! Now I had heard of the trailing slash problem, but couldn’t find a suitable solution that would be easy to implement.

So How Do You Fix It?

I am so glad I am surrounded by lots of smart people. A quick conversation with my friend Rob Sanheim turned up the solution.

I added the following to my .htaccess file:

DirectorySlash Off

I added it after the Options +FollowSymLinks +ExecCGI and before the RewriteEngine On

Now things are back to normal again. I am now able to get back to connecting model railroaders.

Last night, Adam Keys and I did a little ping pong pairing for the Dallas.rb meeting. It was fun. Of course it highlighted how much I have to jump back to the Ruby docs to get much done. But I don’t see that as a problem, since it leaves more room in my head for other things. It also showed my lack of regex-fu.

Here is the code we worked on. We were trying to solve the Ruby Quiz Credit Card problem, and got most of the way through. The fun part about pairing was bouncing ideas off of each other. Others in attendance were also helpful with their suggestions. It was especially interesting as we looked back over the code and discussed even more ways to clean it up.

Would I do it again? You bet. But I think next time, I would like to work on something that I am more comfortable with, like a Rails related app. I love writing specs for that.

After my last post, I thought I would share what I use for developing on Ubuntu.

Editor

I have always been a hands-on kinda guy, so I don’t use any of the fancy IDEs. Right now, I am using SciTE for two reasons. It feels lightweight and it is available for Linux and Windows. Since my laptop does not have a lot of memory, a lightweight editor is a must. I tried Eclipse, but it chewed up all my memory and slowed things to a crawl. So SciTE with some additional plugins (and information on getting them going) powers the development at McKinney Station.

Ruby and Rails

I am using the latest Ruby and Rails for all new development. For testing I am using RSpec, which seems a lot more intuitive to me. Other gems I have installed include:

• FasterCSV – parsing CSV files
• starfish – simple Ruby Map/Reduce
• mongrel – lightweight Ruby web server
• hpricot – Ruby HTML parser

Database

I love starting all of my development projects with SQLite. It is so easy to get up and running. As the project matures, I am able to quickly switch development over to a MySQL database with a change in the application’s database configuration and a quick rake db:migrate.

Version Control

All source code versioning is done with Subversion. With this quick little script, I can get a Rails project committed and started in minutes.

Conclusion

I am always looking for ways to speed up my development process, but so far this is working for me. And it is very enjoyable.

I have come across a few situations recently where testing is a second class citizen in the development process. The latest was a job posting where the part of the development environment was described as “testing when possible.” A lot of the larger projects I have worked on have 1 or 2 weeks of testing tacked on to the end of the development cycle. More times than not, this “testing” time becomes padding for development schedules that overrun. Besides “you tested as you developed, right?” and “we can’t move the delivery date.”

I am becoming more and more an advocate of writing automated tests. This has become even more important when I am the sole developer on a project. Now you might say to yourself, “If there is no one else to mess up the code, shouldn’t everything work?” It does work. But as I come across areas of code that need to be refactored, because I am DRYing up my code, I want to be sure that my changes do not break existing functionality. Now I could make the changes and then manually try to test all of the possible scenarios, but I usually miss one or two, especially in more complex applications. This is where the automated tests come in very handy.

photo by mcconnell6

Maybe I am thick, but writing tests using JUnit or Test::Unit never seemed natural. It always seemed to go at the end of my development cycle. Maybe it was the vocabulary implying that something had to exist to be tested. Maybe it was the unnatural language of assertions: assertTrue, assertThis, assertThat. Who talks like that?

Then I came across something that encouraged me to write specifications for an application that could then be used after the development was complete to verify that the specifications were met. All of the sudden I was discussing how the application should behave, which does not imply that the application even exist yet. This makes sense to me. I saying things like “this should equal that” or “something should have 5 of these”. It is subtle, but powerful.

So I am now using RSpec, the Ruby implementation of Behaviour Driven Development, for all of my projects. My latest Rails project has only 6 models and 2 controllers, but has over 200 specs. I have a better understanding of how the application is supposed to behave. Combine that with a way to continously re-run the specifications when the code is changed and I am now a lot more confident that my changes aren’t breaking existing functionality.

Plus, it’s cooler, right?