Peter Williams

Selenium

I finally got around to setting up Selenium and writing a few tests yesterday. I have been meaning to do that ever since Charlie pointed it out to me a few months ago. Man, I wish I hadn’t waited. Selenium is easily the best way to test a web app that I have every tried. With Selenium your application is tested in the same environment it will be used, in the browser. And it is easy to use, to boot.

Just to be clear, Selenium is not a replacement for unit tests¹. It is a functional or acceptance testing tool. It is slower² and its results are probably less specific than those of most unit tests. However, if you need to verify that your application actually works from the users perspective (and you do) Selenium is the tool for you. The tests are run in the target browser(s) so the tests fail when the user would see a failure, even if the problem is some esoteric browser compatibility issue.

If you are developing web applications and you are not using it already give Selenium a try. You will not regret it.

Postscript: Trouble in paradise

I am having one problem with Selenium, though. It is really, really slow in Internet Explorer 6 on my Ubuntu box. A test suite that takes 1 minute 15 seconds in Firefox take 12 minutes and 42 seconds in IE (same machine, network, etc). I expected IE to be slower, both because it is IE and because it is running under Wine but expected the difference to be percentages not orders of magnitude. If anyone has any ideas about how to make Selenium run faster in IE on Linux I would love to here them.

Mini Vacation in Colorado Springs

For Labor Day we took the kids on a mini-vacation to Colorado Springs. There are a lot of touristy things to do near Colorado Springs.

The first we went to Cave of the Winds. Cat and I enjoyed the tour but Elliot thought was a little boring. He did find a quite few a bits of it interesting but you are not allowed to run and jump and touch everything which makes things a little harder for the the three year old set.

That afternoon we rode the Royal Gorge Railroad. It is an excellent way to spend the afternoon. Elliot loves trains and mountains so getting to ride a train though the mountains was great. It is even better when you make choo-choo noises.

And Audrey loved the wind in her hair on the open observation car.

The next day we went to the Garden of the Gods. The scenery is simply amazing and both Elliot and Audrey love rocks.

This week-end was also the annual balloon festival in Colorado Springs. We did not manage to make it for any of the mass ascents – they happen early in the morning – but we did go to the balloon glow Sunday evening which was very cool.

Even the drive home was nice. We came back to Denver the very indirect way though the mountains. I got to see the real South Park for the first time and it was definitely worth the extra couple of hours.

This was our first vacation in about two year and it was nearly perfect. Hopefully, it won’t take another two years before we do it again.

Megalomania in Revision Control Systems

The more I work with Perforce the more annoyed I get with it’s belief that it is the center of the software development process. Not that Perforce is not unique in believing this. In fact, many commercial revision control systems have this same megalomania.

So, commercial revision control vendors, let me clue you in. Revision control systems are not the center of the software development universe, the file system on the developer’s machine is. Period. The primary job of a revision control system is to figure out what the developer did, after the developer has already done it, and to save that so that it can be applied to the other developers local file systems.

I am complaining about this because out of the box Perforce does not include a way to examine your working directories and get a list of what has changed since the last time you synchronized with the depot (Perforce’s word for a repository). This means that you must declare any changes you make to the source code tree before, or at the same time as, you make them. If you do not declare the changes up front it is almost certain that some required changes will be forgotten and will not get checked in.

The main problem with this approach is that it compels you to break your flow. You might not think that just having to execute one additional command would really be that bad. After all, executing a command could probably be incorporated into your personal process and thereby have little or on impact on your flow. In practice, however, it really does break the flow.

The true cost of declaring that a new file will exist with a particular name is not in the act of declaration. Rather, it is in the thought and commitment that such a declaration requires. Every day, I created new classes only to notice a couple of minutes later that it has morphed in to something quite different than what I originally intended. Declaring the name of a new file to the revision control system before I have even created it dramatically raises the cost of such emerging behaviors. To name a file well I need to understand it’s purpose and to do that I usually need to create it and put some code in it to see how it turns out.

Having to declare the name of the file first requires a significant amount of thought and, worse of all, it prematurely solidifies the design. This premature solidification of design is costly both in terms of the time it takes and the quality risks it introduces. Paul Graham makes a compelling case for a fluid approach to software design in Hackers and Painters. Forcing stability on an immature design merely locks in its deficiencies and that is exactly the result of requiring the declaration a file before it is created.

The need to declare modifications and deletions up-front is less onerous. Deletions are easier because, generally, it is easy to understand the consequences of deleting a file because there is only one. Modifications are easier because marking a file at “to be edited” is quite forgiving. Even if you failed to actually modify the file checking it in will have no functional impact. None the less, having to declare you intentions up-front is still annoying, and wasteful since they could be determined after the fact.

If you are a commercial revision control system vendor please take note. You are not, nor will you ever be, the center of the software development universe. Pretending that you are just costs your users time and effort that could be better spent solving real problems.

Mercurial and Perforce

I have been learning two different source control systems in the last couple of weeks. Source control systems are a vital tool in any software development activity so I want to share my impressions of these tools.

Mercurial

I finally got around to setting up a repository for my personal projects¹. For these projects, I chose to use Mercurial. I have been hearing a bit of a buzz around Mercurial for a while and I decided it would do me good to try out one of these newfangled distributed source control systems². So far, I am impressed. Mercurial is easy to setup and use and it seems quite capable.

So far my only real complaint is that Mercurial does not version directories. It only versions files and the directory structure are treated as meta-data about those files. This makes it impossible to have empty directories in the source tree. Not a huge deal but it is annoying at times.

Distributed source control is a bit of a different mindset than I am use to. The sort of source control systems I am familiar with are built around the idea that there is one-true-version of the code and that the one-true-version lives in the central repository. I think it may take a while to get completely comfortable with a source control system that believes that there are lots of versions of a project all of which are equally valid.

My unfamiliarity aside, I like the distributed approach because I think it accepts the reality of software development. There are usually multiple useful and meaningful versions of a particular project at any given time and a tool that embraces that fact ought to work better than one that does not. I need to use Mercurial quite a bit more to be sure it lives up to that promise, but so far it is looking good.

Perforce

At work, the SCM team recently settled on Perforce as our standard source control system and I get to be the first person in my group to use it for a real project. I have been using it for a couple of weeks now and I can say that it is cross platform³, reliable, fast. Those are all virtues, unfortunately Perforce falls way short on the ease of use.

For example, you might think that something like p4 rename old_name.rb<br /> new_name.rb would rename the file but in fact it just prints this

See ‘p4 help rename’ for instructions on renaming files.

And when you run that it prints a bit of text outlining a multi-step process, involving branching the file and then deleting the original, that will result in the file being renamed.

If you want to edit a file, don’t even think about just opening it with favorite editor and going to town. No, you need to explicitly inform Perforce that you are going to edit the file by running p4<br /> edit myfile.txt. As far as I can tell, Perforce does not have a way to list what you have changed since the last check-out (or sync in Perforce terminology).⁴ This means that you cannot just edit and change to your hearts and then notify perforce of the changes in a batch, no you have to interrupt your flow to inform the source control system that you are about to change a file.

The requirement to manually “open files for editing” and similar issues would probably be easier to deal with using the Perforce Emacs integration but I really despise tools that require IDE integration to be usable. Variety’s the spice of life. Sometimes Emacs will do it, sometimes – not often, but sometimes – I like the idea of using vi.

I have used much worse source control systems than Perforce but I would never choose it over the veritable cornucopia of better, and free, source control systems available.

No RubyConf for Me

Last week I was on vacation and did not touch a computer for six days. That was nice except that the organizers of RubyConf¹ choose that week to open registration for RubyConf 2006. It sold out the first day², of course. That means that I am not going to RubyConf this year, even though it is being held within driving distance of my house. I guess I can live vicariously through the blogs of people who are going.

Anyway, if anyone reading this is going and would like to meet up and have a beer while you are in Denver send me an email.