6 comments

• 

  James Estes

  1 year 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.
  reply
• 

  Andrey Shchekin

  1 year 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.
  reply
• 

  Jeroen van Menen

  1 year 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
  reply
• 

  Andrey Shchekin

  1 year ago

  Yes, of course.
  reply
• 

  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
  reply
• 

  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 :-)
  reply