Using WATIN for Integration Tests

time to read 2 min | 364 words

First, let me say that the guys behind WATIN are cool, they are using Rhino Mocks :-)

Anyway, after my last post on the subject, I got a ton of suggestions to try WATIN, so I did. I like the API, it is taking full advantage of fluent interfaces, and the resulting code is very readable. It wasn't hard to move the code over from Selenium to WATIN, and I feel that the code that we have now is clearer. It is important to note that the API has a .NET feeling to it, which means that the API is far more discoverable as far as I am concerned. There is good documentation and code that I can read and modify :-)

In fact, using Attach To Process I can even debug the web server as the tests are running, and find the problems. It is actually the case that I have discovered a bug in our code because the code was failing

For performance reasons, I tried to keep a single browser open for the whole test fixture, the problem is with the browser cache, which broke my tests horribly when I run them. The problem was that I am regenerating the database at each test, and the browser was remembering the ids from the previous tests, which were no longer valid. After I figured what the problem was, I moved to opening/closing the browser per test, which I am not sure I am happy about.

This is an exteremely interesting way to look at integration tests, and something that I am pretty sure that I would like to try out.

Wish list:

  • Running the tests in the background, right now running the tests basically keep me away from the computer because IE keeps popping up.
  • A way to assert the HTTP Response Code, so I know a request has succeeded or not.