All interaction tests are now lazily instrumented with Istanbul
to obtain code coverage. The interactions tests can be started
with `COVERAGE=1` to obtain coverage. For that, the Mocha hooks
perform the eventual reporting and gathering of data. The instrumentation
is performed in the components server itself.
To make sure that we perform the minimal amount of work required
(since code coverage instrumentation is computationally expensive),
we preload pages to populate the instrumentation cache. Every
interactions tests should preload an example (most likely basic.html)
to populate the cache. Every subsequent test will then use the
already-instrumented code, rather than computing the code over
and over again.
The eventual code coverage is written to /interactions-coverage.
The results will eventually be merged with /karma-coverage
to obtain the union of both unit and interaction tests coverage.
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Bug: 1206705
Change-Id: I5e19b1ecef23d21107210699cb29800556e0415e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2879986
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
The component server needs to inject CSS and JS scripts into each
example. It was doing this by relying on a <style> and <script> tag as
the hook to inject more code. But if you have an example without a
<style> or <script> tag, it won't work. Instead we now inject based on
the </head> and </body> tags, which will always exist (or, if they
don't, we have bigger problems!)
Bug: None
Change-Id: Id2f586c917ee7ab0821d5ab8e50e5cd3d3647a92
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2815131
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
The current tests try to figure out the root directory and then glob
for _test.ts files within there, but this breaks easily if the folder
structure isn't exactly as expected. Instead we can set this via a
flag in the test runner.
This CL only updates the interaction tests, which use the new runner.
e2e tests will be supported in time.
Bug: chromium:1186163
Change-Id: I198b67bf0081ce7334c40d7d661fb8642c2d56d0
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2772045
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This CL adds two flags to the new test runner for configuring the
components server and then updates the server to detect those values.
Note that whilst this CL adds yet-another-way to configure the
components server, this is only being done for backwards compat whilst
we roll out this change to all the various places. We will remove old
options towards the end of this work.
Bug: chromium:1186163
Change-Id: I4c9b85a5745b9fe36894e3c492952938a5b8f648
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2763875
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
It seems there is no requirement for these files to be split; they don't
seem to have a logical split and they are both injected into the `body`
element when DevTools runs. If we kept both of these files around, we'd
have to inject them both into the component docs helpers, and deal with
both of them when it comes to figuring out where legacy CSS variables
are defined.
To make it a bit simpler I've merged `inspectorStyle` into
`inspectorCommon`. I went this way because:
* `inspectorCommon.css` is (I think!) a better name than `inspectorStyle.css`
* `inspectorCommon.css` was bigger.
I also drive-by disabled the stylelint `comment-empty-line-before`,
which was forbidding empty lines before any CSS comments; which made the
entire file feel very squashed!
Bug: none
Change-Id: Ifaa834c7bf56291561e2e5cc124c4efd85c3cc56
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2716285
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Now the server can serve from the tests directory, it will sometimes get
two requests for the same file, one prefixed with front_end and the
other not. If that happens the server now redirects the request such
that we only ever serve each file once and the browser doesn't
double-execute a module.
Change-Id: I14b44aad8b16d1c3f2f787082c70532a8f8776e9
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2599746
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Most of the time we won't need this fully fledged environment, but for
some things (such as context menus, guess what I'm working on right now
:D) we do need a faked out environment to enable these features to run
when we run the component in isolation in the component docs.
Note: while this CL contains no component docs changes that take
advantage of it, I've tested locally with context menus in the data grid
and this change does work.
Fixed: 1148323
Change-Id: Ic8c508840a20b6d0f0e72fd7019a16271f04bea6
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2597313
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
On the bots these tests will run in out/Release but the component server
logic for figuring out the path to the gen directory was wrong; it
navigated up from its position into the root dir, and then back in to
`out/TARGET`. Rather than do that, we instead just walk up from the
scripts dir until we end up in the out/TARGET directory. That way
regardless of if we run in out/Default or out/Release, the script will
find the right directory.
Bug: 1153281
Change-Id: I1d369e47b9931ade60bc86ff52aea7105f10cefd
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2575086
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
As part of the work to enable Puppeteer component tests, we need to
configure the test suite to run either the hosted mode server or the
component docs server. This CL updates it to take a flag, and makes some
updates to the component docs server, which now has to run either
directly or in the out/Default/gen directory depending on how it is run.
I suspect I'll make a follow up CL to always run the component server in
out/Default/gen, but for now enabling it to detect its context is the
quickest way to unblock running it in tests. The next CL will add a
component test suite that can run a basic test against the component doc
server, but I have manually verified locally that I can run tests
against that server.
Bug: 1153281
Change-Id: I55bda4edd0a983d03bfecff0446b0f3e3a008b52
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2562707
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
This CL updates the component docs server so it automatically injects the new
colour variables (which are part of the dark mode work) into the server. It
contains the following changes:
1. Pulling out the new colours into a new CSS file,
`ui/themeColors.css`, which contain all the new definitions.
2. Injecting that new file where we inject `inspectorStyles.css`
currently.
3. Updating the component docs server to intercept any requests to load
an HTML example file, read the HTML contents and inject a `<style>`
tag to load in the theme colours.
4. Additionally we now provide a small bit of JS that adds a handy
button to toggle light/dark mode without needing to dive into the dev
tools.
Fixed: 1152774
Change-Id: Ia2df0e00315dfeb532570ea5634fa54677337f76
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2560941
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
In Devtools-Frontend we load images without a leading slash, e.g.
url(Images/checker.png). This works within devtools, but breaks this
component server as the path ends up as
/component_docs/my_component/Image/checker.png. So we check if the path
ends in Images/*.* and if so, remove anything before it. Then it will be
resolved correctly.
Fixed: 1128914
Change-Id: I476165d16b19713b3c095d5969fac95a5d26a678
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2414190
Reviewed-by: Kateryna Prokopenko <kprokopenko@google.com>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
This CL adds the `ElementsBreadcrumbs` component and documentation to
the component server.
Important: this CL *does not add the component to the UI*. That will be
done in a follow up CL once this has shipped and we have done some other
infrastructure work that is currently blocking components going into
production.
This is also why the file is called `NewElementsBreadcrumbs`, to avoid a
nameclash with `ElementsBreadcrumbs.js`. In the CL that puts this
component into production I will change the filename as the clashing
won't be an issue.
Change-Id: I8039d314ba02c834c3f8ec26f9bdb547858aa2dd
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2236405
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Tim van der Lippe