Since people seem to agree that this is a good problem to solve, I've created a 
bug for it:
I can't promise to fix it myself right this moment as I'm spread a bit too 
thin, but if someone wants to help or pick it up before I get to it please feel 
free :)

From: ext Benjamin Poulain <<>>
Date: Saturday, February 9, 2013 10:57 AM
To: Noam Rosenthal <<>>
Cc: "<>" 
Subject: Re: [webkit-dev] Testing feature suggestion: animation/interaction 
pixel-results "on the fly"

On Sat, Feb 9, 2013 at 1:24 AM, 
<<>> wrote:
I did not say they cannot be tested with the two methods suggested :) It's more 
 about a preference to move some of those decisions from the test 
infrastructure to the test itself, but potentially those bugs could be tested 
in either way.
Examples for bugs I've encountered/reviewed and can use better in-motion 
testing (note that those are specific to Qt/EFL, but I'm sure there are tons of 
bugs like this that come up for Apple/Google as well)

Controlling the clock and programmatically sampling the end result would 
definitely make those more testable, but of course any progress in this area 
would be beneficial and my preference to a canvas-based API is more of an 

To explain my concerns:
Sometime, I look at a failing test, and think: "what the f**k is this supposed 
to test?". Then I have to dig a ton of logs, and finally read the change to 
understand a the single JS statement in the whole script that make the test 

This is the situation I am afraid with a solution where pixels would be 
evaluated from JavaScript. You can test, but you lack visibility why something 
is correct or incorrect. Text tests, ref-tests and pixel tests have a great 
readability, you can quickly evaluate their correctness. This is important in 
my opinion, I don't think we want more opaque output like the RenderTree dump.

I am not against your plan if the readability of the tests can be good. I'd be 
happy to review patches toward testing dynamic changes in webpages.

webkit-dev mailing list

Reply via email to