You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
jianglk.darker
7ee447c011
|
4 months ago | |
---|---|---|
.. | ||
README | 4 months ago | |
gen_smoke_tests.py | 4 months ago | |
save_logs.py | 4 months ago | |
util.py | 4 months ago |
README
These scripts help generate the libcore TEST_MAPPING smoke tests, i.e. a set of tests to run on every change, chosen to run as many as possible in less than some time limit. The process is as follows. 1. Do `source build/envsetup.sh` and `lunch <whatever>` as normal. 2. Run the CtsLibcoreTestCases tests to generate logs to extract timings from. This can be done with `atest CtsLibcoreTestCases` as normal. Make sure to use an appropriate device (virtual or physical). 3. Do that two more times. We'll use best-of-three timings, since sometimes a test takes an unusual amount of time (perhaps because of GC pause or other jank) and it should not be excluded for that. 4. Run the save_logs.py script to copy the logs from out/ to libcore/smoketest. (Empty that directory if it exists already). This is interactive and allows you to pick the runs you want. (If you prefer, you can run this after each run, rather than once after all three runs.) 5. Run the gen_smoke_tests.py script to generate libcore/TEST_MAPPING. 6. Check stdout from the script looks okay (not too many warnings, sensible numbers, etc.). 7. Check the generated TEST_MAPPING looks okay. 8. Do e.g. `time atest --test-mapping libcore` to check it runs okay. 9. Delete libcore/smoketest/ once you're happy. 10. Submit the new TEST_MAPPING. The scripts take no options. There are some constants at the start you can adjust. (These could be converted to command-line options if convenient.) See comments in the scripts for more on how they work. At time of writing, with the current configuration, this generates a sensible number of classes to exclude, so the TEST_MAPPING looks reasonable. If this list becomes too long, we'll have to find a way to simplify it, by rolling up to a higher granularity. Given the way that atest et al are configured, that will probably mean excluding more things. TODO(peteg): What about PTS?