Ivan Sanchez

In our last coding dojo, instead of a randori we had a kata prepared by Danilo Sato. He solved the Minesweeper problem in ruby in about one hour using proper TDD and stopping for questions/suggestions from the audience. Here are some of the tricks people could learn from that session:

• When working with ruby on a Mac, the RSpec bundle for TextMate is great. It has really helpful shortcuts and can easily run your specs and see your reports inside the editor.
• Rspec can be used as a TO-DO list during the development of a class. This can be done by creating pending tests as reminders of test cases to be covered. These are tests appear “yellow” state, waiting for a proper implementation.
• Autospec is also a great tool for TDD. Seeing a test becoming green is fun, but doing so without running it manually is way better. Specially using Growl.
• When doing a presentation using the command line, it’s easy to be tricked by font colors. They may look great on screen, but a projector may not like them.
• During TDD, it’s really important to know how to fake it. But knowing when to refactor the fake code is even more.
• Being able to create methods like “[]” in ruby can be really helpful.
• TextMate allows you to run any text file or even just a few lines of it as a ruby script . This can a good alternative to play with the language instead of using irb.
• A piece of code can sometimes be used as a good visualization tool for a problem. Here’s an example:

    it "should find neighbours around cell" do
      @field.neighbours_at(1, 1).should have(8).neighbours
      @field.neighbours_at(1, 1).should include([0, 0], [0, 1], [0, 2],
                                                [1, 0],         [1, 2],
                                                [2, 0], [2, 1], [2, 2])
    end

• It’s easy to create bugs by using “…” instead of “..” in ruby ranges.
• Multiple assignments FTW.
• jUnit should have something like nested describes in RSpec. It’s a great way to group related tests for a single class.
• Nice RSpec reports can be generated even outside TextMate by using “rspec –format html”
• In BDD sometimes makes more sense having multiple assertions inside the same test. The condition in this case is that they should all help to verify a single behavior of the class being tested.
• Being able to refactor a field into a method without having to care about the references to that field is really cool.
• Assertions for boolean values in rspec are very elegant.
• The pending feature in rspec can really good for big refactorings. It helps to be sure a test or more should be failing during the process.
• Creating your own matchers can make a rspec test more readable. And people should use this feature from jUnit more too.
• It’s easy to get confused by the use of &block and yeld in ruby. In any case, it’s better to learn both and stick to only one of them whenever possible.
• Some ruby conventions are really smart. Append “?” to describe a boolean method, or “!” to do the same for a method which changes the internal state of the class.

If you want to check the source code it’s available on github. To know more about the dojo and or attend our next session check our mailing list for the discussions going on.

Work Coding Dojo, Kata, Programming, Ruby, TDD

In an area dominated by acronyms like DRY, YAGNI, FIRST, SMART, KISS or catchy expressions such as Fake It Till You Make It and Baby Steps, a very important practice which is becoming forgotten is Programming By Intention:

This is the practice of pretending that classes, functions, procedures etc. exist (even though they do not) as you structure and write your code. This helps a developer think about the overall process and larger steps of software rather than the small details.

Although it may sound a little weird, the definition above really points to essence of this practice: pretending a piece of code is there to help you focus on the bigger picture. It forces us to think about what we’re trying to achieve instead of going into all the details first. And this small change in priorities makes a huge difference.

As critical thinkers we are always breaking the problem into smaller pieces and trying to put them together like a puzzle. And sometimes we decide to build these pieces one by one in sequence, and not by importance. By adopting this approach we lose great opportunities to learn early about the solution we’re building. We also lose time refactoring and throwing out code when we realise the pieces could be arranged in a simpler or more understandable way.

And that’s where the beauty of Programming By Intention lies: it effectively helps us to make sure we’re solving the problem first, and writing all the support for the solution later. And that’s why I wish there was a buzzword for it too.

Work Agile, Craftsmanship, Programming, TDD

Then is time to visit TDD Problems:

The aim of this site is to contain a growing collection of software problems well-suited for the TDD-beginner to learn Test-Driven Development through problem solving.

Today the site contains 20 different “real-life” problems, which is probably enough to keep anyone busy for a long time. And since it was announced in the testdrivendevelopment list only a few days ago, it’s very likely the list will keep growing.

Enjoy!

Work Coding Dojo, Programming, TDD

If you’re interested on the slides I’ve used on yesterday’s presentation about my tips on Selenium RC, you can download them here.

If you want to learn more about the practices I mentioned,  here are some useful links:

• The Page Object design pattern in details
• How to use Selenium Grid on the Amazon EC2
• Configuring tests to run in parallel using TestNG

Work Page Objects, Patterns, Programming, Selenium, Talks, TDD, Testing

Then it’s time to try the Way of Testivus:

• If you write code, write tests.
• Don’t get stuck on unit testing dogma.
• Embrace unit testing karma.
• Think of code and test as one.
• The test is more important than the unit.
• The best time to test is when the code is fresh.
• Tests not run waste away.
• An imperfect test today is better than a perfect test someday.
• An ugly test is better than no test.
• Sometimes, the test justifies the means.
• Only fools use no tools.
• Good tests fail.

Work Programming, TDD, Testing