Skip to content

Latest commit

 

History

History
104 lines (68 loc) · 3.65 KB

test_instructions.md

File metadata and controls

104 lines (68 loc) · 3.65 KB
Raw

Test Lacros

Please read Build instructions first. This document focuses on testing related topics.

Instructions for Google Employees

Are you a Google employee? See go/lacros-test instead.

Overview

Depends on which workflow you use, they support different test targets.

Building and running on a Linux workstation.

See Lacros: Test instructions(linux).

These tests are running on CI: linux-lacros-tester-rel and CQ: linux-lacros-rel.

  • Lacros gtest unit tests
  • Lacros browser tests
  • Lacros Interactive_ui_tests
  • crosapi tests: lacros_chrome_browsertests
  • Ash browser tests that requires Lacros: Only On Linux ChromeOS. (linux-chromeos-rel).
  • Version skew testing: lacros_chrome_browsertests, interactive_ui_tests.

Building on a Linux workstation and running on a physical ChromeOS device.

See Lacros: Test instructions(DUT)

  • Lacros gtest unit tests
  • Lacros Tast tests: On ChromeOS DUT/VM(lacros-amd64-generic-rel, lacros-amd64-generic-chrome, etc)
  • Version skew testing: Lacros Tast tests on ChromeOS DUT/VM(lacros-amd64-generic-chrome-skylab, lacros-arm-generic-chrome-skylab)

Building on a Linux workstation and running on a ChromeOS VM running on the same Linux workstation.

Same as above.

What tests should you provide for your feature?

gtest unit test

Unit tests should always be provided. We’re targeting per file unit test coverage of 70%.

Lacros browser tests

This refers to the tests in the browser_tests target. If your test is primarily testing that your feature should work on Lacros, and your test will not cause Lacros to call mojo crosapi, you should add a Lacros browser tests. crosapi browser tests (lacros_chrome_browsertests) If you’re testing crosapi, you need to add your test to lacros_chrome_browsertests.

Ash browser tests require Lacros

If your test is primarily testing Ash, but also requires Lacros to present, you should add ash browser tests. The main difference is that browser() call in the test will return an ash browser instance.

Note: if it’s fine to use lacros browser test or ash browser test, then please add lacros browser test. Lacros browser test only start Ash once, then create new Lacros for every test case.

However for ash browser test, for every test case it starts Ash as wayland server every time, and then starts an ash browser and a Lacros browser. So in theory, for the same test written in different approaches, Lacros browser test is faster and more stable.

Tast test

If your feature is hard/impossible to test on Linux, you should provide a Tast test running on real cros devices or cros VM.

Lacros related builders

CI/CQ linux lacros builder runs unit tests, browser tests, version skew tests.

CI builder using official gn args and running some Tast tests on DUT.

Corresponding arm builder.

CI and optional tryjob for running lacros tests with dbg gn args.

And also various of ash builders like chromeos-eve-chrome. If your cl only changes ash, you can check ash builders which ensure your ash change doesn’t break lacros.