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 <le...@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 <jam...@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 <o...@chromium.org> wrote: >>> >>> On Thu, Apr 29, 2010 at 11:39 AM, Alexey Proskuryakov <a...@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@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
