DISQUS

James Estes · 2 years ago

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.

Andrey Shchekin · 2 years ago

I completely agree with you on user tests.
But what I was writing this time was closer to JS unit tests — something like "changing the selected value in a combo box should change some property of a global object on the page".

Basically I wanted to fix fragility of my javascript and didn't want to do it with more javascript. Even if WatiN would have to call up the browser for each test fixture.

Jeroen van Menen · 2 years ago

Hi Andrey,

I recently added the code from Ayende to WatiN. Now I read your code and it looks even better. Is it OK to include this in WatiN?

Jeroen van Menen
lead developer of WatiN

Andrey Shchekin · 2 years ago

Yes, of course.

Gerald · 1 year ago

Hi Andrey,

Newbie here. How do I get the WatIN document object to pass and what string code to need to send in.

Thanks,
Gerald

James · 1 year ago

Thanks for this post Andrey - awesome piece of code that was a breeze to add to my test suite - keep up the good work :-)

smita · 4 months ago

will these scripts help me to recognize radio buttons on Java script pop up?

Andrey Shchekin · 4 months ago

I think this can be done easier (without really involving JS).
But I have not worked with Watin for a year so I do not really remember anything.

dk · 3 days ago

I've been working to create some extension methods to support CSS Selectors in WatiN. It makes element selection much more natural, especially if you are already using something like jQuery. You can check it out at http://bit.ly/7kiQdL .