The tast command currently only supports running tests from a single test executable: the "run" subcommand has a -testtype flag that specifies whether remote_tests should be executed directly or local_tests should be executed on the DUT.
I can think of several reasons why it'd be handy to support running tests spread across multiple executables, though:
a) Tests suites executed by builders will probably want to include both local and remote tests. Right now, this would require running the tast command twice and parsing each invocation's results. (The tast command will also currently report an error if the test expression matches zero local or zero remote tests, which probably isn't what we want.)
b) We could have tests that are only relevant for a specific Chrome-OS-derived project, or that exercise not-yet-public features, and we might want them to live somewhere outside the public tast-tests repository and not get built into the tast-local-tests or tast-remote-tests packages.
I should probably focus on a) first, since b) will be a bigger task (the tast command needs to know how to find the other binaries, ideally it'd be able to build and push them, etc.).
All of tast's local tests currently get compiled into a single local_tests executable, with remote tests going into a single remote_tests executable.
We could have tests that are only relevant for a specific Chrome-OS-derived project, or that exercise not-yet-public features, and we might want them to live somewhere outside the public tast-tests repository and not get built into the tast-local-tests or tast-remote-tests packages.
I wrote a doc exploring this at http://doc/1yDKFq9ec7myS3X1CkWxqLDB5h564DhC6SohG7ClH0Fc/edit#heading=h.8g692re4e6re.
I'm using issue 793124 to track the related-but-distinct task of running both local and remote tests in a single run.
Comment 1 by derat@chromium.org
, Dec 5 2017