--trace-to-file for Chromium tests

[Adrienne Walker]

If you're running a test in Chromium[0] and want to understand what
it's doing using tracing, you can use the shiny new --trace-to-file
command line flag. By passing that, it traces the default set of
categories into a trace.json file, which can be loaded into
chrome://tracing.

You can specify --trace-to-file=categories to filter what you want and
--trace-to-file-name=filename to specify a filename other than
trace.json.

[0] ...that derives from base::TestSuite.

[Nasko Oskov]

Why not use the existing flags --enable-tracing/--enable-tracing-output? Those work for browsertests today, so it makes sense to reuse them now that there is unittest support.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
    http://groups.google.com/a/chromium.org/group/chromium-dev

[Adrienne Walker]

2014-09-25 13:48 GMT-07:00 Nasko Oskov <na...@chromium.org>:
> Why not use the existing flags --enable-tracing/--enable-tracing-output?
> Those work for browsertests today, so it makes sense to reuse them now that
> there is unittest support.

I considered that, but those flags (and support classes like
TracingControllerImpl) are in content/ so are not usable elsewhere.
It wasn't just a question of moving the files either, as they have
things like BrowserThread baked into them.

[Nasko Oskov]

I didn't mean use the implementation itself, but reuse the flag names. This way running the test one needn't have to remember the distinction. The argument definitions are in content/public, so they can be used from anywhere.

[Adrienne Walker]

2014-09-25 13:57 GMT-07:00 Nasko Oskov <na...@chromium.org>:
> I didn't mean use the implementation itself, but reuse the flag names. This
> way running the test one needn't have to remember the distinction. The
> argument definitions are in content/public, so they can be used from
> anywhere.

They can't really be used from anywhere, since you have to link in
content to get content_switches.cc. Also, it turns out that as
browser tests use base::TestSuite too, if the switches were named the
same thing then both the content trace to file and the base::test
trace to file code would run.

It looks like I have a bug to fix, though. Apparently,
--trace-to-file for a browser tests causes a DCHECK in TraceEventImpl
because it's trying to use MessageLoopProxy when tracing from multiple
threads. Maybe if I get that working then I can just remove the
content/ version of --enable-tracing and just keep the base::test one.

[Sami Kyostila]

Thanks for adding this, this is great!

- Sami

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
    http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Stephen Chenney]

For those of us who've forgotten, which flag works in content shell with layout tests?

Cheers
Stephen

[Dana Jansens]

On Fri, Sep 26, 2014 at 10:59 AM, Stephen Chenney <sche...@chromium.org> wrote:

For those of us who've forgotten, which flag works in content shell with layout tests?

content_shell is not a unit test suite, so it is not affected by this change. 

[James Robinson]

content_shell isn't a unit test target, but it is a content target so the --trace-startup family of flags work:

https://code.google.com/p/chromium/codesearch#chromium/src/content/public/common/content_switches.cc&sq=package:chromium&type=cs&l=764

- James