When testing isn’t worth the price

I’m just starting to use RSpec for Rails instead of Test::Unit, and with it comes a little novelty: there are separate Controller and View tests (unlike TUnit’s functional tests). At first I thought “hm.. cool”. But after spending the first hours writing tests for views I started to feel very stupid, and the whole thing feels very awkward and unnecessary.

Views are too unstructured and change too often for it to be worth keeping it all tested, and most of the time you’re not testing Ruby code, but HTML, and I don’t think that’s what tests are for. If your controllers are well tested, views should do OK.

As convinced as I am about this, I was feeling a little guilty to just ditch testing like that, so I searched for some supporting opinion and found this post. It agrees with me, so it must be right :) The comments are also interesting. The main idea is that you should just test if the views render without errors and get on with life. Now I just have to find out how to test that little thing.

TestGen4Ruby: One Point Oh

From regular versioning culture, one would think that TestGen4Ruby has just graduated and is now an all-mature big boy. False. Just as a clarification, I’m using the versioning scheme suggested by Rubygem’s manual, which can be summed up as: left number => breaks compatibility; middle number => adds new feature without breaking previous stuff; right number => bugfix, cleanup or some other minor change that doesn’t affect the API.

More explanation and arguments in favor of this strategy can be found at the manual itself.

This new version basically fixes a little problem with the input from TestGen4Web. It’s a dirty little fix that doesn’t cover all cases, because that is impossible from inside tg4rb. To fix this for good, a good many changes must be made to tg4w itself. I’m currently working on this.

Just so the “One Point Oh” spirit doesn’t get totally blown away by the clever versioning policy, there is a graduation of sorts going on for TestGen4Web today: this is the last change that is part of my work during the Google Summer of Code (I didn’t have time to commit this before the “pencils down” deadline so I’m releasing now, but it was coded inside that time window). So from now on I’ll just keep fiddling with it on my own. It is a good feeling knowing that now I have a little (my first!) baby free software project on my hands :-)

Well, to the official release notes already:

Subject: [ANN] tg4rb 1.0.0 Released

tg4rb version 1.0.0 has been released!

* <by Helder Ribeiro>
* <(http://tg4rb.googlecode.com)>

## FEATURES:

* takes an XML with actions from tg4w and outputs stand-alone Ruby code that can be run directly or embedded into existing code (e.g. for test automation).
* can be used as a library or as an executable script.
* takes the xpath from tg4w and uses only enough info to guarantee the uniqueness of the referenced element, allowing the generated script to keep working even with some change to page structure.

## PROBLEMS:

* the generated code is damn ugly.
* a few action types from the XML input still aren’t recognized.
* some dependencies aren’t very clearly sorted out yet. you might find you need something that is not specified. if yes, please report this as an issue in our issue tracker.
* i don’t know, find more and let me know =)

## SYNOPSIS:

Changes:

## 1.0.0 / 2007-08-21
* NOTE: This version breaks compatibility with previous version! Scripts written in previous versions won’t work.
* fixed small bug with escaping single quotes
* API change: changed the visibility of element_by_least_restrictive_xpath in Tg4rbToolbox to private
* API change: created public method element() in Tg4rbToolbox
* provided workaround for bug in xpath from tg4w: now clicks on links work with the link’s text (requires HPricot)

## 0.0.2 / 2007-07-09
* fixed silly import problem on generated script

* <by Helder Ribeiro>
* <(http://tg4rb.googlecode.com)>

[ANN] tg4rb 0.0.2 Released!!

Here’s my Google Summer of Code baby!!! =D If you find any problem with the code or the documentation, please send an email to the mailing list or post an issue in our issue tracker. I’m off to Peru today, so I might not check email too often, but I’ll try my best to keep up. Enjoy!

* <by Helder Ribeiro>
* <(http://code.google.com/p/tg4rb)>

## FEATURES:

* takes an XML with actions from tg4w and outputs stand-alone Ruby code that can be run directly or embedded into existing code (e.g. for test automation).
* can be used as a library or as an executable script.
* takes the xpath from tg4w and uses only enough info to guarantee the uniqueness of the referenced element, allowing the generated script to keep working even with some change to page structure.

## PROBLEMS:

* the generated code is damn ugly.
* a few action types from the XML input still aren’t recognized.
* some dependencies aren’t very clearly sorted out yet. you might find you need something that is not specified. if yes, please report this as an issue in our issue tracker.
* i don’t know, find more and let me know =)

## SYNOPSIS:

Changes:

## 0.0.2 / 2007-07-09
* fixed silly import problem on generated script

## 0.0.1 / 2007-07-09
- Birthday
* <by Helder Ribeiro>
* <(http://code.google.com/p/tg4rb)>

The quest for the difference begins

Selenium Core, Selenium RC, Watir, FireWatir, SafariWatir, MineralWatir, Selenium IDE, TestGen4Web. These are all tools related to doing functional testing of web applications. The first six are concerned with providing an API for driving the browser like a user would. The latter 2 record user actions and output code to reproduce them.

Problem is: each has very, very little documentation. And what exists is severely outdated. You can’t tell one from the other.

I’ll start digging up stuff and posting here to keep my findings in one place.

This presentation sheds a bit of light on the differences in architecture between the various Selenia. It’d be great to find the contents of the presentation besides the slides.