Web UI Testing Part 2: Front-door testing tools

Because of the two problems I mentioned with back-door web testing (changes to layout and no Javascript testing), I was looking to pursue front-door web testing toward the end of 2012. 

My first thought was that whatever framework I chose should have a test recorder so that writing the tests would be much easier than having to code up every little click and wait.  The problem with this philosophy is that most of these test recorders generate code.  It turns out that generating code in a maintainable way is hard, and all code should be maintainable, even test code.  So although recorders can be useful in learning how to write tests I eventually scrapped that path, and started looking at using a nice API to drive the browser.

I looked at two different frameworks in .NET for accomplishing this: WatiN and Selenium.  Both had great feature sets and either one would have been suitable.  At the time, Selenium's documentation was way too fragmented.  There were multiple versions: Selenium 1.0, Selenium RC, Selenium 2.0 , etc.  Because I was new I wasn't sure which one to use (e.g. was 2.0 stable?).  When I did a search I ended up on a blog posts using outdated methods, or the blog posts didn't indicate which version of the API was being used.  I found WatiN's documentation to be much clearer on the .NET side.  I went with that, although both tools offer an API which is easily to understand.  I later ended up regretting my choice.  WatiN only supported IE, and although the bulk of the bugs were in IE, I found a few bugs on the other browsers that I wished I had a way of automating.  WatiN later started supporting Firefox after I finished the project.

[Update: Selenium has been on version 2.0 for a while, and the older documentation is becoming less relevant in search engines, so I would probably go with Selenium today]