Reorganize Android's test scripts into packages.

Reorganize Android's test scripts into packages.

This is the first attempt at splitting the scripts into
meaningful packages and make dependencies explicit.

BUG=167331
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=175441

[shashi, 2012-12-19 21:46:27]

lgtm
If I understand correctly, this is reorganizing the pylib directory in
pylib.gtest, pylib.instrumentation, pylib.python_driven. 
Make sure to test this with your downstream patch as this will break ToT bot.
I assume most developers would be using run_instrumentation_tests.py in their
personal scripts so it should not break developer workflow, else you may want to
send a PSA.

[craigdh, 2012-12-19 22:17:19]

lgtm. As you brought up offline, should run_tests.py be named run_gtest_tests.py
to be more in line with the naming of the other test runners?

[Isaac (away), 2012-12-20 06:50:24]

Let's get Marcus's input on this before changing.

[bulach, 2013-01-07 14:30:27]

lgtm

good modularization, thanks!

points to note:
- discussed with ilevy this morning, he'll discuss with you renaming
"instrumentation" to "junit", so make sure you guys agree and are consistent :)
(either way is fine by me).

- agree with craig, but would remove the  "_test" suffix and just keep
"run_gtests.py"..

- I don't have any better suggestion, but would appreciate anything for "python
driven" tests :)
maybe "host_driven" tests would be clearer? as in, the test themselves (more
than just the harness) are driven by the host, unlike the other tests... wdyt?

[frankf, 2013-01-07 20:10:32]

On 2013/01/07 14:30:27, bulach wrote:
> lgtm
> 
> good modularization, thanks!
> 
> points to note:
> - discussed with ilevy this morning, he'll discuss with you renaming
> "instrumentation" to "junit", so make sure you guys agree and are consistent
:)
> (either way is fine by me).
> 
> - agree with craig, but would remove the  "_test" suffix and just keep
> "run_gtests.py"..

Will do in a separate CL.
> 
> - I don't have any better suggestion, but would appreciate anything for
"python
> driven" tests :)
> maybe "host_driven" tests would be clearer? as in, the test themselves (more
> than just the harness) are driven by the host, unlike the other tests... wdyt?

Good idea -> host_driven.