[webkit-dev] Testing changes to CodeGenerator*.pm

[Adam Barth]

IMHO, run-webkit-tests should run all the various webkit testing
scripts and we should have a run-layout-tests script that does what
run-webkit-tests does today.

I'd also settle for a run-tests scripts that was the ASAD testing script.

Adam


On Thu, Apr 29, 2010 at 12:16 PM, David Levin <levin at chromium.org> wrote:
> Just curious, would it be less maintenance if the test run was integrated
> with run-webkit-tests?/Is the concern about having lots of different tests
> harness to run to verify a change?
> dave
> On Thu, Apr 29, 2010 at 12:11 PM, James Robinson <jamesr at google.com> wrote:
>>
>> 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.
>> - James
>>
>> 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
>>>> behavior.
>>>
>>> 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
>>> thing.
>>> 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
>>> apparent.
>>> Ojan
>>> 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
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>