rice and beans

Ok, here’s the last translation, it’s the brazilian-portuguese version of the Scrum Checklist:

Here’s another brazilian-portuguese translation of another excellent presentation by Henrik Kniberg entitled “Technical Debt - how not to ignore it”.

Some like to say that the best way to learn is to learn from your own mistakes. Maybe, but it might be of great help if you can learn from other people’s mistakes as well.

The great Henrik Kniberg from “Scrum from the Trenches” fame and other excellent agile-related articles, has presented “10 ways to screw up with Scrum and XP” and I’ve asked him if I could translate it to brazilian-portuguese, which he kindly accepted.

So here it is:

When asked about how to convince management about Scrum I basically go around about risk reduction and ROI, since these are the main things people at the higher management level care about.

The #1 reason for project failure according to the CHAOS research is lack of customer involvement. So why not use a process that eliminates that risk?

Using a incremental process significantly reduces the risk of wasting money on something that’s not going to be useful, because the customer helps steer the product development in the right direction through series of planned feedback cycles.

Also, with a incremental process you start delivering something in a much shorter time than when using a waterfall approach, which effectively increases the ROI (return on investment), since the customer starts benefiting from the product after one or two months, instead of waiting 6 to 12 months in a typical waterfall project.

You can also mention improved customer satisfaction, team self-improvement and self-management, which reduces the administrative overhead, improved employee satisfaction and a bunch of other more intangible advantages.

This is a little presentation I’ve made to go with a talk I’m giving at my company this week. I try to make it clear why, at our industry, we need to stop doing manual testing once and for all and find ways to integrate testing as a whole into the development cycle.

I believe we already have plenty of good enough tools nowadays to achieve this in almost any case. It’s just a matter of acknowledging the cost of not doing it.

On the other side, the benefits of doing it are enormous, so just do it! Your team will be much happier and your customers will be very pleased as well.

In my job, we build a lot of desktop applications. They used to be written mostly in C++ for sake of performance a long time ago, but we’ve migrated all apps to Java, since Swing got to a reasonable level of performance these days.

Since I’ve got there in 2005, I’ve been preaching loudly about the benefits of test-driven development and managed to get quite a lot of people infected with the test-first bug.

However, we’ve got a lot of legacy code. I mean A LOT, really. That kind of code that was never meant to be tested in isolation, and unfortunately, will never be.

That doesn’t mean we can’t make use of automated testing. We just have to go up all the way up to the UI to be able to do it. I know, it’s slow and brittle but it’s much better than nothing.

I’ve been working a lot with Cucumber and investigating it deeply to see if that could be the missing piece we needed to make testers and developers really work together, so we could free ourselves from the manual testing hell.

Cucumber also makes UI testing a lot less brittle and easier to maintain since we can change the UI and keep the tests we already got, having only to fix the step definitions mostly.

That’s why I started writing Swinger. Swinger is a collection of step definitions that you can use to automate testing in Java/Swing applications. It makes use of the Jemmy library to find and manipulate Swing widgets.

It’s still very experimental and it has a long way to go before I can release it as a gem, but so far I’ve been able to write some interesting and mildly complex test cases with it.

I’m using the SwingSet demo application that comes with the JDK as my test bed and it’s quite fun to watch Cucumber drive it crazy in a matter of seconds. Wanna take a look? Check it out:

HQ is highly recommended for watching the video.

I’d really like your help to make Swinger as good as it can be. Care to join me?

http://github.com/demetriusnunes/swinger/tree/master

UPDATE: This functionality turned into a patch and got into Cucumber as a built-in formatter. Use cucumber -f steps to use it.

For at least a minimally interesting inaugural post, let me explain the name of the blog:

Rice and Beans is a very frequent food combination seen in Brazil, which food experts believe to be a healthy foundation for a lot of typical brazilian dishes due to the mix of carbs and proteins.

Now, to something really useful. This is a little rake task I wrote to printout any Cucumber step definition for your project. It is very hackish, but it works for now. I intend to turn this into a proper formatter and add it to Cucumber.

desc 'List all step definitions'
task :steps do

  # let's collect all steps in this hash, grouped by source file
  $steps = {}

  module Cucumber
    class StepDefinition
      # let's override the step constructor to 
      # capture the necessary information
      alias_method :old_initialize, :initialize
      def initialize(regexp, &proc)
        caller[1] =~/.+\/(.+)\./
        $steps[$1] ||= []
        $steps[$1] << regexp.to_s[8..-3]
        old_initialize(regexp, &proc)
      end
    end
  end

  # require the files containing the step definitions,
  # so they get all instantiated and captured
  require File.dirname(__FILE__) + '/path/to/your_steps.rb'

  # printing out results
  $steps.keys.sort.each do |file|
    puts file + ":"
    $steps[file].sort.each { |s| puts "  " + s }
    puts
  end
end

And you get this kind of output on your console when the task is ran:

checkbox_steps:
  I click the checkbox "([^\"]*)"
  the checkbox "([^\"]*)" should (not )*be selected

combobox_steps:
  I change the combobox "([^\"]*)" to "([^\"]*)"
  I should have the combobox "([^\"]*)" with "([^\"]*)"

dialog_steps:
  I close the dialog "([^\"]*)"
  I should (not )*see the dialog "([^\"]*)"
  the dialog "([^\"]*)" is the container
  the dialog "([^\"]*)" is visible