There are a lot of common developer workflows when it comes to testing. This document details those. Workflow 1Developer already has a built system using build instructions. Developer wants to create a copy of their image for testing and build Chromium OS tests without re-running build_packages.cros_sdk and run mod_image_for_test on the chromiumos_image.bin (if you get complaints of unmount errors, sudo umount /media/* outside the chroot).Workflow 2Developer has a testable image on their device. Developer makes modifications to the python component of a test and wants to re-run the test on the target system.If the user makes modifications on the host system, the easiest way to re-run the tests is to re-run run_remote_tests. That script takes local changes from third_party/autotest before running tests. However, if the developer wants to make changes to dependencies of their tests, the developer must re-run build_autotest.sh Workflow 3Developer wants to run a test with certain conditions met on the host system before the system is ready for that test e.g. "browser is not running and has never run since boot".For tests that require system-wide setup and system-wide cleanup, the best approach is probably to create a server-side test that sets up the environment, reboots the system, runs the test and cleans up the system. This should not be done for very small tests as rebooting is rather expensive. Take a look at BootPerfServer as an example to write such a test.Note in the long run we want to create utilities that verify certain conditions. If you are interested in writing one of these utilities, please email the dev list. Workflow 4Developer wants to run a test that requires a user to be logged in.Subclass your test from site_ui_test.UITest Note we are trying to create a utility for such pre-req's as login, so make sure to leave a big todo with DoLogin in it so that we can update your tests once they the utility libraries are ready. |
