Andrey Shchekin's Blog - Latest Comments in Evaluating Javascript in WatiN

Re: Evaluating Javascript in WatiN

Page Brooks — Fri, 06 Sep 2013 13:19:23 -0000

The WatiN API has changed and the above code does not work without some changes. I made some small modifications and enhancements here:

https://gist.github.com/pag...

Re: Evaluating Javascript in WatiN

dk — Sun, 20 Dec 2009 12:56:16 -0000

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 .

Re: Evaluating Javascript in WatiN

Andrey Shchekin — Wed, 29 Jul 2009 19:28:43 -0000

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.

Re: Evaluating Javascript in WatiN

smita — Wed, 29 Jul 2009 15:59:58 -0000

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

Re: Evaluating Javascript in WatiN

James — Thu, 10 Jul 2008 04:37:34 -0000

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

Re: Evaluating Javascript in WatiN

Gerald — Thu, 15 May 2008 18:14:35 -0000

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

Re: Evaluating Javascript in WatiN

Andrey Shchekin — Thu, 20 Sep 2007 16:21:17 -0000

Yes, of course.

Re: Evaluating Javascript in WatiN

Jeroen van Menen — Tue, 18 Sep 2007 10:18:21 -0000

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

Re: Evaluating Javascript in WatiN

Andrey Shchekin — Wed, 12 Sep 2007 03:38:22 -0000

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.

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.