Comments on: How to check for errors on every page using Watir http://www.natontesting.com/2009/08/19/how-to-check-for-errors-on-every-page-using-watir/ nathaniel ritmeyer's thoughts on automated software testing Thu, 19 Jan 2012 15:37:28 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Robbie Wareham http://www.natontesting.com/2009/08/19/how-to-check-for-errors-on-every-page-using-watir/comment-page-1/#comment-323 Robbie Wareham Tue, 06 Apr 2010 16:59:38 +0000 http://www.natontesting.com/?p=287#comment-323 "add_checker" runs a lot more regularly than just page load. I discovered this when using "add_checker" to keep a copy of the previous page html to report on failure (when investigating a failure, the previous page is often more useful than a screenshot of the page where the error occured, infact errors dismissed as flakey testing turned out to be caching issues because we had the html of the previous page to refer to). The "previous" html was continually a copy of the "current" html, and it was then that I discovered that a lot of events trigger add_checkers. Also, add_checker can easily miss page loads as well. Again while investigating "flakey" tests, I saw that when the application navigated from page A to page C via a quick visit to page B, occasionally add_checker failed to run on page B. Unfortunately the add_checker running on page B was crucial to test reliability! Anyway, these are my observations on add_checker, and you'll be pleased know that test reliability is much improved now that I fully understand add_checker. “add_checker” runs a lot more regularly than just page load. I discovered this when using “add_checker” to keep a copy of the previous page html to report on failure (when investigating a failure, the previous page is often more useful than a screenshot of the page where the error occured, infact errors dismissed as flakey testing turned out to be caching issues because we had the html of the previous page to refer to). The “previous” html was continually a copy of the “current” html, and it was then that I discovered that a lot of events trigger add_checkers.

Also, add_checker can easily miss page loads as well. Again while investigating “flakey” tests, I saw that when the application navigated from page A to page C via a quick visit to page B, occasionally add_checker failed to run on page B. Unfortunately the add_checker running on page B was crucial to test reliability!

Anyway, these are my observations on add_checker, and you’ll be pleased know that test reliability is much improved now that I fully understand add_checker.

]]>