Articles Feed

Craftsman Swap Day 1

by: jim | April 14th, 2009 |

My initial impression of the Obtiva office is the relaxed atmosphere. It consists of a big, open work area with lots of pairing stations. At the beginning of the day, I jumped right into an internal stand up meeting with a few of the Obtiva folks. It was short, sweet and to the point. One interesting difference between this and the way I’m used to doing stand ups is items that would normally be handled as followups were discussed during the individual updates. The discussions never wandered far, so this worked quite well. I was paired with Tom Kersten most of the day on some client work.

While working with Tom, I was introduced to a few tools that I hadn’t used before.

• Fluid, a Site Specific Browser that basically allows you to sandbox a web application in a dedicated browser process. You can Command-Tab to an icon that you assign, and if (or more accurately, when) your browser crashes, Fluid does not.
• GNU Screen, a window manager that removes the latency from remote pairing. Of course, you need to use an editor like vi for it to work for you.
• Text Expander, which does exactly what it says: you specify shortcuts, e.g. brb, and it will expand it to the full text, e.g. Be right back.
• Rak, a Ruby replacement for grep. It gives you the line number of the matched text, which regular grep can do too but it always takes me 5 minutes to figure out the right option to pass to get it to work.

Tom’s editor of choice (even for Rails development, which is what we were working on) is VI. I was a little worried at first, but I picked up a few tricks and it didn’t slow me down quite to a crawl like I had anticipated. We were also using Cucumber to test-drive the features we were working on; this was Acceptance Test Driven Development (ATDD) in that the test represents the behavior that the software should have. I have been test-driving my Rails code at a lower level (think model and controller), and I think that there is a ton of value in moving up to a higher level to define the behavior.

As we were implementing a feature, the following problem presented itself. We’re using Webrat in the step definitions of the Cucumber tests. The way Webrat makes you click on buttons/links is slightly problematic. You can use the text or the id of the link to tell it to click. The text is probably the least permanent part of the entire link, so by relying on the text your tests are inherently fragile. By adding an id for all the links in your application, you are cluttering up the DOM. Adding an id to all your elements is a valid solution, and one that have fallen back to in the past. But this seemed backwards; the testing is forcing us to clutter up our HTML. The testing framework should be working for us, making it easier to write valid, uncluttered HTML. Perhaps we could use the href attribute of the anchor tag to click a button? Unfortunately, Webrat doesn’t support that, but it is open-source so I ended up forking and adding this feature. However, after more discussion, I’m not convinced that this approach is indeed better than using the id approach.

2 Responses to “Craftsman Swap Day 1”

1. Subhash Chandra Says:
   April 15th, 2009 at 05:40 AM

   IMHO, Xpath is the best way to go in the given situation, provided your testing toolkit supports it. You can base your selectors on those that are logically static. If there is nothing like that and everything is changing then probably you don't want to test it or you don't want the test to pass when if changes. :)

2. Jim Suchy Says:
   April 15th, 2009 at 11:13 PM

   I would tend to agree; however, in this case, Webrat was limiting our selectors to either the text in the link or the id of the tag. I don't believe it allows xpath or css selectors, at least not to simulate clicking a link.

Leave a Reply

Name (required)

Mail (will not be published)

Website

#