[LRUG] Details for your cuketober meeting

Glenn Gillen glenn at rubypond.com
Sat Oct 9 03:31:32 PDT 2010


> Even something seemingly superficial as changing the name of a selector may mean you have to edit a step or two that depend on that selector. More profound changes are even more cumbersome to retrofit in the tests.
> 
> The redoubled work load works against the creative impulse: Imagine sketching something and then having to leaf through your book to a different page to update a model every time your sketch took a new, unexpected turn. Not to overdramatize, but this slowly but surely kills the creative process.

For all of my criticisms of Cucumber, I don't think this is a problem specific to it. All it really is is a different way to write the language of your test, it shouldn't have to drastically change the way your test. What is important is that your test is actually testing the things you care about, In my instance it took having to refactor a large codebase that we'd done it wrong in to realise how important it is to get it right first time. It's not only more productive, your test suite is more reliable as a result.

So I would take a guess that if you're having to go and update tests because you've changed a selector, you're doing it wrong. If you're a stickler for semantic HTML markup then it's unlikely that the selector would change as the meaning of the content would still be the same. If your using the appropriate <div>, <p>, <h*> , <label>, etc. elements then your markup should be fairly consistent. Changes in design will impact the CSS and possibly the order of the elements in the markup, but rarely the selectors you need to test them. Because what you care about is "Does this page have a label to inform the user that the text box next to it is where they input their home phone number" and not "Is there a text box in 'div div div p label.foo'".

Where that has been problematic in a current project is javascript testing the display of data using a javascript framework (ExtJS specifically) because it generates some truly horrible HTML with very little in the way of semantic meaning. The way we've ended up testing that though is having a test along the lines of "And I see 'Foo' in the 'Bar' column" which will first go and find the table header cell for the "Bar" column, pull out the dynamically generated selectors on it, then use them to find the relevant cell in the main body of the table. It's not as elegant as I'd like, but it means we can (and have) change the order of the columns, or remove ExtJS altogether (which we're doing), and everything will still pass.

I try to ask myself before a couple of questions when I write each test:

* Does the name/description of the test state clearly the desired intention, or is it explaining a technical implementation? If it's the latter, redo to make it the former.
* If I completely change the implementation will the test still pass? If it won't, then rewrite it so it will pass.

The worst situations I've seen a code base get to is where you know the app is broken but the tests are passing (too much mocking of implementation) or the app is working but the tests are broken (tests are too specific to underlying implementation). Both render the test suite useless.

Glenn


More information about the Chat mailing list