[webkit-dev] Testing changes to CodeGenerator*.pm
jamesr at google.com
Thu Apr 29 12:11:28 PDT 2010
As a concrete example, I found this test setup helpful for this patch:
http://trac.webkit.org/changeset/58345. A nice side effect was that it
revealed a bug in CodeGeneratorGObject.pm and let me fix it without having
to set up build setup for whatever it is that uses the GObject bindings.
I agree that golden file testing is a very high-maintenance fragile test
method, but it's better than nothing. If this framework didn't exist then I
would have likely made the change and relied on spot checking and our
existing automated tests to catch any regressions which is less than ideal.
On Thu, Apr 29, 2010 at 11:44 AM, Ojan Vafai <ojan at chromium.org> wrote:
> On Thu, Apr 29, 2010 at 11:39 AM, Alexey Proskuryakov <ap at webkit.org>wrote:
>> On 29.04.2010, at 11:17, Yaar Schnitman wrote:
>>> I've been using the tool for a couple of patches in V8. It really boost
>>> the development cycle, helps reviewers understanding what a cryptic perl
>>> block of code actually does, and side effects are easy to find. Once you
>>> start using it, its becoming hard to work without it. Give it a try!
>> 'm thinking about how this tool could have helped with the CodeGenerator
>> changes I made in the past, and it seems that it wouldn't have detected any
>> changes, and could require me to find creative ways to test the new
> I don't really follow the what the maintenance overhead is. How does this
> actually cause you more than a trivial amount of extra work? Maybe a
> specific example would help.
> Isn't this just like having a layout test with expected results? It's a
> small isolated test instead of testing everything. That seems like a good
> More importantly, it lets you be sure that every feature of the code
> generator has some testing. In the real IDLs, a feature might stop getting
> used temporarily and then changes to the code generator would not be readily
> P.S. Sorry for the double-post some of you got. Sent from the wrong email
> address at first.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev