Richard Lawrence

At a client today, we were doing some tricky automation with WatiN (against Telerik controls) in Cuke4Nuke. We wanted to dig into what WatiN was finding in the browser. The obvious move was to fire up the debugger. But with Cuke4Nuke, this is trickier than you might think. The Cuke4Nuke gem includes a release build—no debug symbols. Plus, the process isn’t around long enough to attach to if you use the cuke4nuke executable. We probably could have figured it out, but it wasn’t worth the trouble.

Since we weren’t debugging the Cucumber side of things, we didn’t need all the Cucumber and Cuke4Nuke plumbing. We just needed to run the code using WatiN.

NUnit and Resharper to the rescue…Cuke4Nuke cares about Given, When, Then, Before, and After attributes on your methods. But that doesn’t mean those are the only attributes allowed. Read the rest of this entry »

Gojko Adzic has a new blog post demonstrating the new table parameter support in Cuke4Nuke. Table parameters are an important part of Cucumber. They’re great for setting up data and asserting that lists are what you expect. But I use them much less often than the other kind of table in Cucumber, scenario outlines. Read on to see how to use them »

This morning, I released version 0.3.0 of Cuke4Nuke. With this release, Cuke4Nuke supports almost everything you can do with Cucumber in Ruby or Java, making C# a first class language for Cucumber. (The only missing features are small things like tags on Before and After hooks and a richer Table object.) Check out the Cuke4Nuke wiki for instructions to install and get started with Cucumber in .NET. To see it in action, check out my screencast on Cuke4Nuke and WatiN.

Effective agile teams get things done. They build software day after day that’s not just “code complete” but really shippable. And when their product owner says, “ship it,” they can get their shippable software into production at the drop of a hat.

The Definition of Done can be a powerful tool to make these things happen…If it’s used right.

Most agile teams I see have one of four relationships with a Definition of Done:

1. They don’t have one
2. They have one but don’t really use it
3. They have one but can never satisfy it
4. They have one, satisfy it for each story, but still have lots to do at the end of a release

I rarely come across teams who use the Definition of Done to good effect day after day, sprint after sprint. Find out why and how to fix it »

Yesterday, I released Cuke4Nuke 0.2.2, which added WatiN compatibility and an example of how to use the two tools together. Here’s a short screencast in which I walk through the example:

Resources from the video:

• The Cuke4Nuke Wiki with installation instructions
• WatiN
• Source code from the example
• The new Ruby installer

Work shouldn’t suck. Whatever your position, you can do something to make your work better.

I’m so thankful for the work I get to do, I want to share the goodness. So here’s my crazy Thanksgiving offer: If you subscribe to this blog or follow me on Twitter and you don’t love your job, tell me about it, and I’ll help you find one thing you can do to make your work better. I can’t promise it’ll be easy or safe, but it will be worth doing. We spend most of our lives working—it should be great.

Email me: richard at humanizing work dot com.

Oh, and if your work doesn’t suck, share why you’re thankful for it in the comments here. If you need a head start, check out Bob Hartman’s list of things agile teams can be thankful for.

After a long hiatus, I’m resuming the WatiN Patterns series. Pattern #1 covered why and how your tests should clean up after themselves. Pattern #2 covered how you should name your tests and why they should only assert one thing.

Pattern #3 is about keeping your tests maintainable by specifying just enough in your element selectors.

Read the rest of this entry »

Good user stories follow Bill Wake’s INVEST model. They’re Independent, Negotiable, Valuable, Estimable, Small, and Testable. The small requirement drives us to split large stories. But the stories after splitting still have to follow the model.

Many new agile teams attempt to split stories by architectural layer: one story for the UI, another for the database, etc. This may satisfy small, but it fails at independent and valuable.

Over my years with agile, I’ve discovered nine patterns for splitting user stories into good, smaller stories. Read on »

Update: If you’ve just landed here, you could get the impression from this post that Cuke4Nuke doesn’t exist yet. It does. Check out this screencast showing what you can do with it as of early December 2009.

If you’ve read this blog for a while or talked with me about functional test tools, you’ve heard me talk about Cucumber. It’s my favorite ATDD tool because it’s so good at mapping stories and acceptance criteria to automated functional tests. Product Owners and BAs write acceptance criteria in natural language. Developers and testers unobtrusively automate tests for them. Anyone on the team can run the tests and see the current state of the system.

Here’s a simple example:

Feature: Google search
    In order to find things on the web
    As a user
    I want to search for web pages containing specific text
 
    Scenario: Load search page
        When I go to the search page
        Then I should be on the search page
 
    Scenario: Search
        Given I'm on the search page
        When I search for "richard lawrence"
        Then I should see "www.richardlawrence.info" in the results

This reads almost exactly as I teach Product Owners to specify acceptance criteria. But it’s not just text. It’s a potentially automated test.

A developer or tester can come along and automate this test like so in Ruby:

# assuming @google is an instance of a test DSL that wraps Watir, Selenium, etc. 
 
When /^I search for "(.*)"$/ do |query|
  @google.search_for query
end
 
Then /^I should see "(.*)" in the results$/ do |expected_text|
  assert { @google.results_contain? expected_text }
end
 
# etc...

Each of the Given/When/Then calls is a step definition. When there’s a matching line in a Cucumber test, the step definition gets executed.

Recently, support was added for step definitions in Java via a project called Cuke4Duke:

@When("I search for \"(*)\"")
public void search(String query) throws Exception
{
    google.searchFor(query);
}
 
@Then("I should see \"(*)\" in the results")
public void checkResults(String expectedUrl)
{
    assertThat(google.containsResult(expectedUrl), is(true));
}

Now, a Java team can use Cucumber without ever writing a line of Ruby.

Unfortunately, there’s nothing like this for .NET teams. Until now (or soon, anyway)…

AA-FTT and the Birth of Cuke4Nuke

Last month, I attended the Agile Alliance Functional Test Tool conference (AA-FTT for short). AA-FTT is an open space conference. I came with one goal: to get together with other people who want Cucumber for .NET and start making it happen. I wasn’t sure anyone else would be interested, so I was thrilled with the reaction.

Aslak Hellesøy introduced Cucumber for those in the group who hadn’t used it and then talked through the multiple language support he’d recently added to the tool. Then, we discussed ways to build .NET support. The obvious solution was to use IronRuby and Cucumber’s language support to handle C# step definitions. Matt Wynne downloaded the latest IronRuby and installed Cucumber on it. He kicked off a simple Cucumber example, and we waited. And waited. Some two minutes later, we had results from tests that take less than two seconds to run under the standard Ruby interpreter. In a process that values frequent, fast test runs, IronRuby was a non-starter. (If you want to try Cucumber under IronRuby, here are some instructions.)

So we discussed other options and settled on using a simple wire protocol for Cucumber to communicate to .NET out-of-process, similar to Slim in FitNesse. And here’s the best part: we started building it. Matt and I paired right there to start fleshing out the wire protocol (with Cucumber tests, naturally). Later in the week at Agile 2009, Matt and Aslak paired to build the Ruby side of the wire protocol, and Matt and I tackled the first bits of the .NET side. Last week, I got the skeleton of the .NET side working and up on GitHub. You can define simple steps in C#. Cucumber can ask the .NET wire server to tell it about the steps it has and to invoke them and return the pass/fail results.

About a week ago, Aslak announced the project on the Cucumber mailing list and recruited more contributors. Declan Whelan, Scott Ford, Åsmund Eldhuset, Anders Hammervold, Chris Kooken, and Steve Eley have already stepped up with ideas and code.

Getting Involed

How can you get involved? I’m glad you asked.

1. Join the mailing list.
2. Fork the GitHub repository and work on one of the features in the backlog.
3. Post a message to the mailing list to let us know what you’re working on. I’ll tag the ticket in the backlog with your GitHub username so we don’t duplicate effort. Prefix your message subject with [Cuke4Nuke].
4. Comment on tickets in the backlog.
5. Try using Cuke4Nuke as we develop it and give us feedback via the mailing list.
6. Shout encouragements in the comments here and on Twitter to let us know you care, even if you can’t contribute.

For those who attended my Agile 2009 presentation with Bob Hartman, “The 7 Deadly Sins of Almost Being Agile,” here are the slides and handouts.

Slides

Evaporating Cloud Cheat Sheet Handout

Evaporating Cloud Template Handout