Getting Cucumber/Webrat to talk to outside sites with Mechanize

here's a great link for me to remember on using Cucumber/Webrat/Mechanize to automate/test remote sites:

http://blog.jcoglan.com/2009/10/03/getting-started-with-cucumber-rspec-webrat-and-multiruby/

My current podcasts

Been listening to for a while

Astronomy Cast
Rails Envy
The Thomas Jefferson Hour
WNYC's Radio Lab
Pragmatic Podcasts
My History Can Beat Up Your Politics

Just picked up

This American Life (used to listen on the radio)
Stuff you Missed in History Class
The Moth Podcast
Dan Carlin's Hardcore History

Me meme

Well, I got it from enrique, so that's my picture. Here's the rules, I guess:

1. Take a picture of yourself right now.
2. Don’t change your clothes, don’t fix your hair…just take a picture. (should be super-easy with Photobooth)
3. Post that picture with NO editing.
4. Post these instructions with your picture

Practice Sudoku Git Repository Approaches

I've been talking for a while about starting a series of git repositories that can be used as tools for doing focused practices, the first of which will be a sudoku solver. This is the story of my initial attempt at setting up the git strategy, having troubles, then having David Chelimsky help me find what I think will be a better way. I am just a beginner with git, so building these repositories is also a way for me to practice my own git-fu.

I'll write about my initial, failed strategy, then explain the approach that David recommended, as well as paraphrase a bit on the approach we took to get there. Of course, I'm interested in other people's opinions and ideas, as well, so feel free to comment below or write a blog post. I'm planning more of these repositories, so I expect that experience will guide me to a better repository strategy.

Goal: I would like to have a git repository that contains a set of cucumber features for a sudoku solver. These features would contain many sudoku boards of differing difficulty, allowing someone to bypass the initial bother of finding boards to use in practice session.

While I'm building the features, I am also going to be writing a sudoku solver, as well. I want to maintain a branch with just the features in it, as that will be what is pushed to github.


Attempt 1

branches:
master = cucumber features + step definitions
rspec = rspec examples + implementation

approach:
As I add cucumber features on master, I then rebase over to the rspec branch. The rspec branch will always have the most up-to-date features from the beginning, so I can see if things are still working, as well as access them. The rebasing will put all the feature stuff at the start of my commit tree, so it will be a similar situation to someone who is using it after all the features are written.

result: massive pain
This worked great until I started having to make some small changes to the features/support/env.rb file to include my lib code for the features to run. Well, I did it in the rspec branch, since it wasn't related to the core features. Well, this caused some merge conflicts when I was trying to rebase the master over to the rspec branch. Plus, it was a bit confusing to me to have to jump from branch to branch depending on what I was working on.

retrospective:
I only got a reasonable idea of the differences between rebase and merge last week from Tom Kersten, so I had a bit of a naive view of its uses. I still like the idea of having a clean branch with just the cucumber features, but rebasing doesn't seem to be the correct approach.

Why do I even want to have the cucumber features all placed at the beginning of my commit history on the actual implementation branch? Why not just merge? With hindsight (and perhaps a bit of foresight would have been good), my initial idea doesn't really hold much water. My commit history is based on the incremental development of the features, so trying to take more recent changes that affect my implementation and pushing them back to the front of the commit log just sounds like a recipe for grief. And, amazingly, it did end with much wailing and gnashing of teeth.


Paraphrase/Summary of Conversation with David

While David was making oatmeal, I explained the rebase/merge conflict problems. After explaining my approach, he started offering some ideas around using rebasing. Pretty quickly, though, he switched his questioning more towards why I was trying to do what I was doing. It didn't take long to get to the heart of what my goal was: have a clean repository that contained just the cucumber features that would be needed to begin implementation of a sudoku solver. Here's the suggestion that David offered, and the one that I'm going to switch to.


Attempt 2

branches:
master = cucumber features + step definitions
implementation = rspec examples + implementation

approach:
Develop entirely on the implementation branch.
Any changes in features directory are committed atomically
Feature commits are marked prominently for easy identification
Master branch gets cherry-picked feature commits merged in periodically
Squash feature atomic commits on master into larger ones, if appropriate

foreseeable result:
Branch 'master' contains clean history of cucumber feature development. Branch 'implementation' contains always working code that actually contains a wonderful history of how I developed the practice features.


A Couple Thoughts


Popping the 'why' Stack

While David and I were talking, there was a definite point when his questions took a turn towards understanding what my root problem was. After a couple of questions, the phrase 'popping the why stack' came to my mind; that was what David was doing. After making it to the root of what I wanted, he was able to offer a solution that satisfied my needs in a much simpler way. When I mentioned 'popping the why stack' to him later, he said, "that's the BDD way."


Tell Don't Ask

Thinking about the proposed approach, it appears much simpler, smoother and more flexible. As I was comparing the two, it occurred to me that this was a form of the "tell don't ask" principle that we use in code. In approach 1, as I'm working on my implementation branch, I'm constantly 'asking' the master for any changes to the features. This means that, over time, we may get more and more out of sync, and I'll run into a situation when it is just too difficult to bring in any changes. In approach 2, I'm adjusting the features alongside the implementation, then I am 'telling' the master branch what changes to merge. Since the master branch isn't really doing anything with them, other than reporting on them to github, it is a much more effective design to tell it the updates.

Test Utilities using extension methods

So, I was working with Jeff McWherter on some TDD stuff in C# today, and I came upon a trick that I really like. When I used to do C#, I was working in the 2.0 version of the .net framework. This meant that, while I had cool things like generics and anonymous methods to help me out, I didn't have extension methods. Well, Jeff and I were working in .net 3.0, so I had the benefits.

We were writing some tests that need a couple instances of a data object. Well, my first test new-ed up the instance and added it to the collection. This instance needed to have the due date property set, so I did something like this:



Well, there's a bit of annoying duplication there, so I changed it to:



with a method later on that looks like this



Okay, a bit better.

A little bit later, we had another test fixture that used the data object in a similar way, so I was looking for a way to bring the thing() method into a scope that was available for the other fixture, as well. When I was doing 2.0, I would have probably built a base class for my test fixtures and subclasses it in both fixtures. Yuk! Those who know me know that I have a special, black, cold place in my heart for subclassing like this.

Enter extension methods

I want a way to have some utility methods that I can use whenever I have a fixture that needs to build things. Aha! Let's make an interface:

public interface TestsThings {}

And, add an extension method to it:



Cool. Now, my test fixtures can implement TestsThings and get the method, so the construction of the lists will now look like this:

Unnecessary Construction Parameters? Yuk!

Well, not happy to leave a bad thing bad, I decided to take it one step further. I want to be able to write



How to do that? Hmm.... Ah, here we go. Let's change ThingTestingUtilities to look like this:



Works much better. But, there is still a matter of duplication in the DateTime.Now... stuff. So, let's take this a step further. What if I could write this:


That looks much better. Yeah, if I was in a different language, I'd do something like:
this.NewThings().WithAnOffsetDueDate(1.days);
[Update: Steven Harman alerted me that you can do this. I'm too lazy right now to implement it, though. Maybe later]
[Update2: Leon Gersin added a comment showing how to extend it like 1.days. Check it out.]

So, let's add a helper method. The utility class looks like this now:



Cool, compiles, runs, now my construction looks like this:



Extension methods can definitely help do some neat stuff. I don't have to subclass, I can add methods by simply implementing an interface. This also gives me the ability to create interfaces that are focused on different tasks that my test fixtures might need, so I don't have to load up subclasses with unnecessary mixes of unrelated methods.