Christopher Wiley | f3fe347 | 2016-03-01 11:31:49 -0800 | [diff] [blame] | 1 | # Autotest: Automated integration testing for Android and Chrome OS Devices |
| 2 | |
| 3 | Autotest is a framework for fully automated testing. It was originally designed |
| 4 | to test the Linux kernel, and expanded by the Chrome OS team to validate |
| 5 | complete system images of Chrome OS and Android. |
| 6 | |
| 7 | Autotest is composed of a number of modules that will help you to do stand alone |
| 8 | tests or setup a fully automated test grid, depending on what you are up to. |
| 9 | A non extensive list of functionality is: |
| 10 | |
| 11 | * A body of code to run tests on the device under test. In this setup, test |
| 12 | logic executes on the machine being tested, and results are written to files |
| 13 | for later collection from a development machine or lab infrastructure. |
| 14 | |
| 15 | * A body of code to run tests against a remote device under test. In this |
| 16 | setup, test logic executes on a development machine or piece of lab |
| 17 | infrastructure, and the device under test is controlled remotely via |
| 18 | SSH/adb/some combination of the above. |
| 19 | |
| 20 | * Developer tools to execute one or more tests. `test_that` for Chrome OS and |
| 21 | `test_droid` for Android allow developers to run tests against a device |
| 22 | connected to their development machine on their desk. These tools are written |
| 23 | so that the same test logic that runs in the lab will run at their desk, |
| 24 | reducing the number of configurations under which tests are run. |
| 25 | |
| 26 | * Lab infrastructure to automate the running of tests. This infrastructure is |
| 27 | capable of managing and running tests against thousands of devices in various |
| 28 | lab environments. This includes code for both synchronous and asynchronous |
| 29 | scheduling of tests. Tests are run against this hardware daily to validate |
| 30 | every build of Chrome OS. |
| 31 | |
| 32 | * Infrastructure to set up miniature replicas of a full lab. A full lab does |
| 33 | entail a certain amount of administrative work which isn't appropriate for |
| 34 | a work group interested in automated tests against a small set of devices. |
| 35 | Since this scale is common during device bringup, a special setup, called |
| 36 | Moblab, allows a natural progressing from desk -> mini lab -> full lab. |
| 37 | |
| 38 | ## Run some autotests |
| 39 | |
| 40 | See the guides to `test_that` and `test_droid`: |
| 41 | |
| 42 | [test\_droid Basic Usage](docs/test-droid.md) |
| 43 | |
| 44 | [test\_that Basic Usage](docs/test-that.md) |
| 45 | |
| 46 | ## Write some autotests |
| 47 | |
| 48 | See the best practices guide, existing tests, and comments in the code. |
| 49 | |
| 50 | [Autotest Best Practices](docs/best-practices.md) |
| 51 | |
| 52 | |
| 53 | ## Grabbing the latest source |
| 54 | |
| 55 | `git clone https://chromium.googlesource.com/chromiumos/third_party/autotest` |
| 56 | |
Christopher Wiley | f3fe347 | 2016-03-01 11:31:49 -0800 | [diff] [blame] | 57 | ## Hacking and submitting patches |
| 58 | |
| 59 | See the coding style guide for guidance on submitting patches. |
| 60 | |
| 61 | [Coding Style](docs/coding-style.md) |
Allen Li | 6f4517e | 2017-12-19 12:54:43 -0800 | [diff] [blame] | 62 | |
| 63 | ## Pre-upload hook dependencies |
| 64 | |
| 65 | You need to run `utils/build_externals.py` to set up the dependencies |
| 66 | for pre-upload hook tests. |
Allen Li | 484946c | 2018-04-20 18:00:38 -0700 | [diff] [blame] | 67 | |
| 68 | ## Setting up Lucifer |
| 69 | |
| 70 | [Setting up Lucifer](docs/lucifer-setup.md) |