Re: Evaluating Javascript in WatiN

James Estes — Wed, 05 Sep 2007 21:12:58 -0000

You should be careful with this approach when writing user/acceptance tests (its better suited for interaction/integration tests to see that events really do get wired up...but then its a slippery slope).

The UATs are meant to be written from the user's perspective. The tests should read that way and reflect what a user would actually do, including how they themselves would verify that an action was successfully completed. The users might even be able to read and understand what the test is trying to do. When you start getting under the hood and fiddling with javascript directly from the test, then it gets further away from being a user test. The user certainly won't be calling javascript to verify that an action they took really did affect the state of the page.

Hitting the javascript also makes the test fragile because it is too tied to the implementation details which make it harder (well just more annoying really) when you want to change the implementation. Why should the (state-based) test care that certain javascript code was called, so long as the end result is that something on the page reflected the expected outcome. With ajax web app testing, this does tend to require some waits, but typically you can get it to wait for a specific expected value to appear or change to happen (i.e. wait for your ajax progress indicator to 'stop' instead of an arbitrary 3000 ms).

When I find myself (instinct) starting down this path, I step back and evaluate what is missing in the ui that is forcing the test to pop the hood. Usually all it needed was a visual indicator to the user that probably should have been there in the first place. Not always. But usually.

Disqus - Latest Comments for James Estes

Re: Evaluating Javascript in WatiN