my not-so-barbaric yawlp

I was able to attend RubyConf and truely enjoyed it. One of the best moments was a discussion that took place during Stuart Halloway’s Refactorum discussion. On the screen he displayed a piece of Rake that he wanted to refactor. With the blessing of Jim, who was sitting in the front row, Stu began the journey. He then showed the unit test that he used to test the private method he wanted to refactor. Unfortunately this is where the discussion got carried. I’ve seen posts by both Jay Fields and Jason Rudolph that talk about the how in testing private methods, and a lot of discussion around the blogsphere about how wrong this is.

Whether you agree with testing private methods or not, people are missing the subtlety of what Stu really did. Taken out of context I feel that the real message was missed.

Tightening the Feedback Loop

The first thing he did was identify a piece of code he wanted to refactor. The piece he found happend to be a private method. This method was fully tested (100% coverage), but it was tested through it’s public interface. If something in the private method was changed, it would have been picked up, but the unit tests were testing a level higher than the method that was being refactored. What Stu did (before performing any of the refactoring) was to tighten the feedback loop. He gave himself a safety net that was closer to the problem being tackled instead of relying on the one that was there. That way, if he broke something in the method he was refactoring, he would know right away instead of identifiying what was broken through a side effect.

Are Integration Tests Enough?

I also saw a suprising post from a highly regarded individual who said they don’t really unit test much. They rely on the integration and functional level tests to make sure that things are working. Yes this made the hair on the back of my neck standup. It goes against everything I believe in as a religious TDD’er. But after thinking it over for some time I realized that it’s all about the feedback level you are comfortable with. If something breaks I want to know about it at the most granular level possible. If you choose to only create functional level tests, and you are using a tool to check your covereage levels (such as rcov) you are still building that safety net, just further away from the actual code.

I know here at EdgeCase we rely on extremely tight feedback loops. We typically deliver projects in terms of weeks, not months, we work in weekly iterations and we test at the most granular of levels. We still rely on integration testing to ensure things work together, but when it comes to the code, the closer to the source, the better.

I realized that I completely forgot to post this up to my blog.

Jim Weirich and I will be teaching a Pragmatic Studio on Testing Rails in Columbus Ohio, October 17-19.

We are preparing some fantastic content to help show attendees what TDD is all about, as well as how to get the most out of your testing. This is as much how to test correctly as it is about how to test Rails specifically. We are taking our years of testing experience in and out of Ruby and showing you how we apply it to Ruby and Rails. We will show you how to test as individuals and in your teams.

We have learned a lot at EdgeCase over the past year about specifics of testing Rails applications, and especially about the fantastic RSpec framework. You get the benefit of having all of the things we have learned the hard way wrapped up in a nice, neat package.

Nicole and Mike have put together a fantastic program with the “Pragmatic Studio” brand and we are honored to be a part of it.

What are you waiting for, register now!

I’m lucky enough to be pairing with Jim Weirich and I’m learning a ton. Of course I’m learning things like how to get the most out of the one true editor and the really hard to understand ins and outs of Ruby.

What I’m enjoying the most is the different perspective on developing in Ruby. We’ve had quite a few discussions about style. The most recent I thought I would put up here.

One or more lines

When you come to Ruby people inevitably ask the question of when to use do … end and when to use the {} syntax for blocks. The normal answer, and the one I’ve subscribed to, is that you use {} if you are on one line, and do … end if you span more than one line.

  Items.find(:all).each { |item| puts item.description }

  Items.find(:all).each do |item|
    # do something
    # do something else
    item.save
  end

Problems with this approach

First, when you decide to add more functionality into your block, you have to change the surrounding syntax. If you are following Red, Green Refactor, this could happen quite frequently.

The most interesting issue we discussed was that this style tells you nothing of value when you are reading the code. We can tell visually that it’s one or two lines.

Use {} when returning a value, do … end when performing actions

The alternative is to use these two syntaxes to communicate what you are doing. Jim’s style of development, which I’m quickly growing more fond of, is to use {} when you are returning a value from a block.

  [1,3,4,5,6].find { |i| i == 4 }

  [1,3,4,5,6].collect { |i| i.to_s }

On the flip side use the do … end syntax when performing actions, but not returning any values.

  %w{ one two three four five }.each do |i| i.capitalize! end

  %w{ one two three four five }.each do |i| 
    i.capitalize!
    i.reverse!
  end

So now when you are glancing through some code and you see a block that looks like this:

  array.method_accepting_block { |item| 
    some_action
    more_actions
  }

you will know that they are returning a value at a glance.

Interesting idea. Thoughts?

As you know we have a contest going on to win free admission to erubycon. All you need to do is tell us some really cool thing you are doing with Ruby.

The latest post is from Josh Schairbaum, a leader in in the community who is working hard to get organizations to take notice. He writes about his experience getting Ruby adopted inside some major corporations. First JPMorgan Chase and now CardinalHealth, number 11 and 19 on the Fortune 500 list respectively.

From his post:

So, what am I doing? In short, I’m helping technology leaderships make the best investment decisions, while becoming an industry leader, not an industry follower. I’m proving to them that you don’t needs teams of consultants or a pricey support contract to business value out of the data that your organization holds. I’m proving that Ruby belongs.

His work at JPMC has grown quite well:

At JPMC, I led the team that created the 1st fully-supported and fully-funded Rails application inside the bank. ... The part that I’m most proud of is that 1 year ago, there were no full-time Ruby/Rails jobs at JPMC, today there are 3, and that’s a great thing for the community.

He’s now moved on to CardialHealth, but has not left his innovative ideas behind:

I’m doing something that I think is even more edge-leading and innovative. I’m in the process of deploying several small Camping apps, which work together to create a dashboard of information for IT leadership to make investment decisions

Read the full text here. You can also listen to the Ruby on Rails podcast with Josh and Dan Manges about their work at JPMC.

It’s exciting to see some of the inroads that Ruby is making, and the developers that are happier because of it.

So I thought it a bit odd to run into Roy, the founder of ThoughtWorks, upon my arrival to RailsConf today. I then get to the speakers lounge, register and find a two page spread announcing not only mingle but also the most interesting announcement of all:

Today ThoughtWorks Studios introduces the convenience, power and flexibility of Ruby / Ruby on Rails to Fortune 1000 companies.

RubyWorks is, what appears to be, ThoughtWorks supporting Ruby for the Enterprise. To say this is huge would be a drastic understatement. ThoughtWorks is releasing a production LAMP stack for Ruby on Rails that’s designed for both Red Hat Enterprise and CentOS (think free version of RedHat). According to their website, beginning in July they will begin offering 24×7 paid support. This is putting your money where your mouth is.

RubyWorks – a new products and support service for Ruby. Designed to help enterprises implement and use Ruby more effectively …

EdgeCase is pushing the meme of Enterprise Ruby with erubycon, and now ThoughtWorks is getting behind it with full support.

This is going to be a stellar year.

update: Edited to fix stupid grammar mistakes. Will stop blogging when jet-lagged.

We were interviewed for the Ruby on Rails podcast. We’ve been excited and waiting for this to come out for the last few weeks.

Hear about how we work, why we got together and what it is about Ruby and Ruby on Rails that excites us.

Jim Weirich is joining the cast of erubycon. Jim is responsible for some of the killer Ruby tools including Rake and Ruby Gems, which he co-created in a hotel lobby using a thumb drive as a CVS repository (you have to ask him about it). Jim is one of the best known Ruby developers who is also spends a lot of his time in old legacy code bases. Jim’s insights into what Ruby has to offer will definitely help us get the point across. erubycon is honored to have him join us.

You can read more about Jim’s passion for open source, software development and Ruby at onestepback.org.

I’m very excited about this. Dave Hoover, a close friend and fantastic developer is going to be speaking at erubycon. Dave has become quite well known in the testing community and is one of the main reason we are able to have Selenium testing in Rails. Dave Hoover has recently moved to Obtiva where he has been giving a very successful Ruby on Rails bootcamp.

Also, note that we now have RSS syndication added to erubycon, so you can keep up to date with the latest developments

Looks like they shipped rSpec version 0.7. If you have used it, please make sure the check the upgrade section of the wiki for notes on where it breaks backwards compatibility.

We have been using it at EdgeCase with great success. Our latest project has been helped by the paradigm shift that rSpec helps bring about in our testing. Plus the output is just like reading a printed spec sheet.

Why upgrade to 0.7? They have made some excellent improvements to the mocking and stubbing libraries, and some awesome improvements to the rSpec on Rails plugin. Most notably, you can test your views independently of your controllers (thanks to ZenTest). You can also test your rjs responses as well.

But the real reason you should check it out:

That’s right, they’ve taken the idea of RedGreen (part of the ZenTest package) a step further and highlighted which specs are passing and which are failing.