Yes, I did consider that. The fatal flaw in that plan is that the webkit test script is single-threaded and runs through the tests in order. Ours doesn't, and so we can't easily guarantee the same sort of output they have. Eric and I will probably work through this as we upstream the code. I'm actually hoping to get them to adopt my output, but we'll see.
-- Dirk On Thu, Dec 10, 2009 at 7:45 PM, David Levin <[email protected]> wrote: > Have you considered making the output closer to that of WebKit's > run-webkit-tests? > It seems that would ease the hopeful transition to this version upstream. > dave > On Thu, Dec 10, 2009 at 7:23 PM, Dirk Pranke <[email protected]> wrote: >> >> Hi all, >> >> If you never run the webkit layout tests, you can stop reading. >> >> Otherwise, earlier today I checked in a patch that should make the >> output much less verbose in the normal case. From the CL: >> >> First, a number of log messages have had their levels changed (mostly to >> make them quieter). >> >> Second, the script outputs a "meter" that shows progress through the >> test run, which is a one line summary of where it's at current >> (e.g. "parsing expectations", "gathering files". During the actual test >> execution, the meter displays "%d tests completed as expected, %d didn't, >> %d remain". The meter uses carriage returns but no linefeeds, so the >> output >> is overwritten as it progresses. The meter is disabled if --verbose is >> specified, to avoid unnecessary confusion. >> >> Third, I removed the --find-baselines option. I think I was the only one >> using it, and --sources is good enough (but added the baseline for >> the checksum as well as the .png when using --sources). >> >> Fourth, there is a new "--log" option that can be used to provide finer >> granularity of logging. It accepts a comma-separated list of options, >> like: >> --log 'actual,expected,timing': >> >> "actual": the actual test results (# of failures by type and timeline) >> "config": the test settings (results dir, platform, etc.) >> "expected": the results we expected by type and timeline >> "timing": test timing results (slow files, total execution, etc.) >> >> All of this information is logged at the logging.info level (if the >> appropriate option is enabled). >> >> Using the --verbose switch will cause all of options to be logged, as well >> as the normal verbose output. In addition, the verbose output will >> disable >> the meter (as mentioned above). Note that the "actual" results will be >> logged >> to stdout, not stderr, for compatibility with the buildbot log parser. >> >> Finally, the list of unexpected results (if any) will be logged to stdout, >> along with a one-line summary of the test run. >> >> The net result is that when run with no command line options (and when no >> tests fail), only one line of output will be produced. >> >> Feedback / problems / questions to me. >> >> Pam, sorry for making all of your examples in your tech talk >> immediately out of date :) >> >> -- Dirk >> >> -- >> Chromium Developers mailing list: [email protected] >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev > > -- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
