Head On

Robby Russell is a constant source of information on Ruby and Rails, I have used his instruction on how to set up Rails and PostgreSQL on Mac a number of times. It is therefore fun to see that I have actually used 3 out of the 5 things he wants to know more about::

RSpec User Stories

We were very early adopters of this one, we started using it the same day it hit trunk in a useable form. Everyone should start using it today - I cannot speak highly enough of it. The only thing I miss is a Fit-style table approach to rules, but I have my own thoughts about that one.

Using Selenium with RSpec

We have used the now outdated spec/ui library at WeMind. Today we use RSpec Stories almost exclusively for acceptance testing. My position is to use Selenium only where you really need it, for example to test Javascript functionality.

JQuery

I have used it for the dynamic hiding of speaker info for Agila Sverige. Not at all enough to judge a library by, but it feels a lot sweeter than Prototype/RJS.

JSSpec (BDD for Javascript)

Yeah, I wanna know more about this as well.

Using the Google Charts API with Rails

Same here.

Other than that I would love to try out:

• Seaside - I have dabbled with it but nothing worth mentioning.
• CouchDB

I am creating a small site using Merb, DataMapper and RSpec, all in all a very enjoyable experience. I did however have problem getting the test database to be automigrated when running the specs, as I am used to in Rails.

As Google did not help, I turned to #merb on IRC, and got immediate help.

Two alternatives:

1. Run rake MERB_ENV=test dm:db:automigrate before running rake specs
2. Insert DataMapper::Base.auto_migrate! into your spec/spec_helper.rb

Big thanks to topfunky, afrench and jdempsey for the help.

Ola has released JtestR 0.1. It seems to b a great tool for those doing Java development. I can personally not imagine doing any development these days without RSpec.

I just read the following in a month old post on the RSpec list:

As someone who uses an IDE, I find dealing with multiple SCMs is a real
pain, and one of the cool things about Ruby has been that
(traditionally) nearly everything’s in Subversion

It might be that Rails will have hard time keeping up with new stuff, both technically and culturally, since it tied really close knots with everything that was cool 2005.

RSpec 1.1: “The RSpec Development Team is pleased as glug (that’s kind of like punch, but more festive) to announce RSpec-1.1.0.”

Woohoo! We’ve used RSpec since the 0.7-ies and I personally could not be happier with it. The RSpec community is really pushing the boundaries for testing/speccing frameworks and is now the standard for all others to follow.

(Via David Chelimsky)

I have used Rails on a daily basis for almost a year now, and before that I was a night time hangaround. While I am definitely a happier programmer using Rails than anything built on Java, I still feel that it can get better.

First of all I want more things to be plugins. And really, they should not be plugins at all but gems instead.

Why plugins? We use RSpec instead of Test/Unit, HAML instead of erb and are seriously looking into JQuery instead of Prototype. And of course, we are using Mercurial instead of Subversion. All of this is of course possible to use in Rails, but a lot of things are sort of made for the default choice, such as generators generating tests, and plugins having the -x switch for Subversion. And I am pretty sure that this is the way DHH wants it.

So, when 2.0 is now released, I see that the Rails community as a whole does not see the same problems as I do. If they did, they would have done more like the stuff above, instead of sexy migrations and ActiveResource.

This is where Merb becomes really interesting. I have looked at it before not understanding its value, but now I see a framework that does everything I want Rails to do. Gems as plugins and very agnostic about templating languages, Javascript frameworks and even ORM frameworks - almost a heresy in Rails. I will definitely think about using it instead of Rails in the future.

I am at the SIME07 conference in Stockholm. It is is a conference focusing on entrepreneurship, media, Internet etcetera, at a pretty high level. At the conferences I normally attend people speak about what thay have done. This one has a lot of “what do you think will happen” going on.

This morning there was a very interesting panel with three venture capitalists on stage, giving feedback to three companies pitches, and VC strategy in general.

Perhaps not spot on for what I do every day, but providing a nice new perspective on things.

I am subscriber of the Test Driven Development mailing list as well as the RSpec ones. One thing that strikes me continually is the lack of innovation and new ideas in the former one, as opposed to the flurry of brilliant ideas constantly coming out of the RSpec one. It seems to me that communities stagnate and that the people who once were the revolutionaries turn into keepers of their own revolutions ideas. The free thinkers become conservative.

Guy Kawasaki gave a brilliant keynote on the MySQL conference, talking about innovation. He said that the only way most people think about how to improve themselves is by using the tools they know more proficiently. No makers of horse carriages became car manufacturers. And the original TDD’ers are still talking about the same things they did five years ago. The revolution has moved on.

The current incarnation of autotest seems to assume that you are using integrated views. If not, you can modify the rspec_rails_autotest.rb file to run the view specs as well:

 
  # when %r%^app/views/layouts/(.*)\.rhtml% then
  #   ["spec/views/layouts/#{$1}_spec.rb"]
  when %r%^app/views/(.*)\.rhtml$% then
    ["spec/views/#{$1}_view_spec.rb"]
 

Your view spec must be postfixed with “_view_spec.rb” for it to work

Update This works out of the box now.

I am getting all parts of my Rails development environment settled. In addition to vanilla Rails, I am currently using RSpec, Selenium and Autotest. I am seriously considering Haml and Sass as well.

When googling arounf to learn more about Autotest, I realized that people are using together with Growl. It works out-of-the-box with Test::Unit, but RSpec needs a little tweaking. I took the basics from here and modified to my liking. The following is what my .autotest looks like.

 
module Autotest::Growl
  def self.growl title, msg, img, pri=0, stick=""
    system "growlnotify -n autotest --image #{img} -p #{pri} -m #{msg.inspect} #{title} #{stick}"
  end
 
  Autotest.add_hook :ran_command do |at|
    puts "at: '#{at.results}'"
    output = at.results.slice(/(\d+)\s.*specifications?,\s(\d+)\s.*failures?/)
    puts "out: #{output}"
    if output =~ /[1-9]\sfailures?/
      growl "Test Results", "#{output}", '~/Library/autotest/rails_fail.png', 2 #, "-s" 
    else
      growl "Test Results", "#{output}", '~/Library/autotest/rails_ok.png'
    end
  end
end
 

After evaluating the previous named contenders for webtest tools, the winner was … none of them.

It dawned upon us that the MaxQ way of doing this, ie. recording tests, really is not the way to go, ever. What you’re really doing is testing the server from a HTTP perspective, without testing button clicking and stuff. For example, all hidden fields must be specified at every request. If you have anything Javascript based you still have no clue if this works after having these funtional tests.

On the other hand, using anything based on HttpUnit actually mimics a webbrowser, so you can click buttons and not have to worry about hidden fields. And yes, Javascript is handled.

jWebUnit is based on HttpUnit, but it has a rather limited API, for example you cannot find a button by its name to click it. We came to the conclusion that it was easier to build our own API on top of HttpUnit.

We also decided to implement the same API in a mock implementation ? la the way it is described in “Testing XP”. This way functional tests can be run very quickly on development machines and the more time consuming remote HTTP tests are done on the integration machines (Yes, we have several, one for every deployment OS).