Please see the the Integration Testing Framework document for more information about specifics.
chrome/test/webapps/generate_framework_tests_and_coverage.py
and verify nothing is outputted to the console.browser_tests
and sync_integration_tests
autoninja -C out/Release browser_tests sync_integration_tests
)--gtest_filter=*WebAppIntegration_*
:testing/run_with_dummy_home.py testing/xvfb.py out/Release/browser_tests --gtest_filter=*WebAppIntegration_*
testing/run_with_dummy_home.py testing/xvfb.py out/Release/sync_integration_tests --gtest_filter=*WebAppIntegration_*
At the end of this process, all critical user journeys be decomposed into existing and new user actions and enumerated in the Critical User Journey Spreadsheet. However, for this step the goal is to create any new actions that those journeys might need. See all existing actions in the Actions sub-sheet, which should give a good idea of what actions are currently supported in the framework.
Given the existing actions:
Please contact the team if you have any questions or trouble here.
The file handlers feature:
What critical user journeys will be needed? Generally:
The existing actions already have a lot of support for installing, launching, checking if a window was created, etc. The following changes will have to happen:
The goal of this step is to implement the actions (or other changes) that were determined by the last step. The action should be tested to make sure there are no bugs and it works on all applicable platforms.
For details about how to implement actions, see Creating Actions in the WebAppIntegrationTestDriver
.
Implementing or changing actions is usually done in WebAppIntegrationTestDriver
. If the action only works with the sync system, then it may have to be implemented in the TestDelegate
interface and then in the TwoClientWebAppsIntegrationTestBase
. See test partitioning for more information.
Adding or modifying sites would happen in the test data directory.
After the action and/or other changes are implemented, one or more “manual” tests should be implemented to ensure that they are working properly. See test partitioning for more information about these various files, but basically:
UninstallFromList
This is an example CL of implementing an action. It:
WebAppIntegrationTestDriver
.Finally, now that the changes are implemented and tested, they can be used in generated critical user journey tests. Please work with someone on the team (see contact the team) to review the new tests being added here and to help make sure nothing is missed. Working together you will add those new tests (and possibly actions) to the spreadsheet so that you can execute the following steps:
This command will download the data from the spreadsheet into the local checkout.
chrome/test/webapps/download_data_from_sheet.py
To have the script actually generate tests using the new actions, they must be marked as supported in the supported actions file. The support is specified by a symbol per platform:
After recording an action as supported here, the next step should generate new tests!
This command will output all changes that need to happen to the critical user journeys.
chrome/test/webapps/generate_framework_tests_and_coverage.py
The output should:
After you make changes to the integration browsertests, please re-run the above command to verify that all of the changes were performed and no mistakes were made.
Possible issues / Things to know:
After all tests are added, git cl format
is often required. It's a good idea to test all of the new tests locally if you can, and then after local verification a patch can be uploaded, the the trybots can be run, and a review can be requested from the team.
If the “manual” browsertest didn't catch a bug that is now failing for the generated tests and there is no obvious fix for the bug, it is OK to submit the new tests as disabled. To do this:
chrome/test/webapps/generate_framework_tests_and_coverage.py
again to update the coverage percentage.Why is this OK? Adding the generated tests can be a big pain, especially if others are modifying the tests as well. It is often better to get them compiling and submitted quickly with a few tests disabled instead of waiting until everything works.
UninstallFromList
Here is an example CL of adding generated tests for the UninstallFromList
action addition. During the development of this action, it was discovered that some of the critical user journeys were incorrect and needed updating - you can see this in the downloaded file changes.
To contact the team for help, send an email to pwa-dev@chromium.org and/or post on #pwas on Chromium Slack.