Robert Ly | 35f2fda | 2013-01-29 16:27:05 -0800 | [diff] [blame] | 1 | page.title=CTS Development |
| 2 | @jd:body |
| 3 | |
| 4 | <!-- |
| 5 | Copyright 2010 The Android Open Source Project |
| 6 | |
| 7 | Licensed under the Apache License, Version 2.0 (the "License"); |
| 8 | you may not use this file except in compliance with the License. |
| 9 | You may obtain a copy of the License at |
| 10 | |
| 11 | http://www.apache.org/licenses/LICENSE-2.0 |
| 12 | |
| 13 | Unless required by applicable law or agreed to in writing, software |
| 14 | distributed under the License is distributed on an "AS IS" BASIS, |
| 15 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 16 | See the License for the specific language governing permissions and |
| 17 | limitations under the License. |
| 18 | --> |
| 19 | |
| 20 | <h2 id="initializing-your-repo-client">Initializing Your Repo Client</h2> |
Clay Murphy | a69844e | 2013-05-30 17:56:38 -0700 | [diff] [blame] | 21 | <p>Follow the <a href="{@docRoot}source/downloading.html">instructions</a> |
Guru Nagarajan | 7a100c9 | 2013-07-23 15:13:01 -0700 | [diff] [blame] | 22 | to get and build the Android source code but specify <code>-b android-4.3_r1</code> |
Robert Ly | 35f2fda | 2013-01-29 16:27:05 -0800 | [diff] [blame] | 23 | when issuing the <code>repo init</code> command. This assures that your CTS |
| 24 | changes will be included in the next CTS release and beyond.</p> |
| 25 | <h2 id="setting-up-eclipse">Setting Up Eclipse</h2> |
Clay Murphy | a69844e | 2013-05-30 17:56:38 -0700 | [diff] [blame] | 26 | <p>Follow the <a href="{@docRoot}source/using-eclipse.html">instructions</a> |
Robert Ly | 35f2fda | 2013-01-29 16:27:05 -0800 | [diff] [blame] | 27 | to setup Eclipse but execute the following command to generate the |
| 28 | <code>.classpath</code> file rather than copying the one from the development |
| 29 | project:</p> |
| 30 | <pre><code>cd /path/to/android/root |
| 31 | ./cts/development/ide/eclipse/genclasspath.sh > .classpath |
| 32 | chmod u+w .classpath |
| 33 | </code></pre> |
| 34 | <p>This <code>.classpath</code> file will contain both the Android framework |
| 35 | packages and the CTS packages.</p> |
| 36 | <h2 id="building-and-running-cts">Building and Running CTS</h2> |
| 37 | <p>Execute the following commands to build CTS and start the interactive |
| 38 | CTS console:</p> |
| 39 | <pre><code>cd /path/to/android/root |
| 40 | make cts |
| 41 | cts-tradefed |
| 42 | </code></pre> |
| 43 | <p>At the cts-tf console, enter e.g.:</p> |
| 44 | <pre><code>run cts --plan CTS |
| 45 | </code></pre> |
| 46 | <h2 id="writing-cts-tests">Writing CTS Tests</h2> |
| 47 | <p>CTS tests use JUnit and the Android testing APIs. Review the |
| 48 | <a href="https://developer.android.com/guide/topics/testing/testing_android.html">Testing and Instrumentation</a> |
| 49 | tutorial while perusing the existing tests under the |
| 50 | <code>cts/tests/tests</code> directory. You will see that CTS tests mostly follow the same |
| 51 | conventions used in other Android tests.</p> |
| 52 | <p>Since CTS runs across many production devices, the tests must follow |
| 53 | these rules:</p> |
| 54 | <ul> |
| 55 | <li>Must take into account varying screen sizes, orientations, and keyboard layouts.</li> |
| 56 | <li>Only use public API methods. In other words, avoid all classes, methods, and fields that are annotated with the "hide" annotation.</li> |
| 57 | <li>Avoid relying upon particular view layouts or depend on the dimensions of assets that may not be on some device.</li> |
| 58 | <li>Don't rely upon root privileges.</li> |
| 59 | </ul> |
| 60 | <h3 id="test-naming-and-location">Test Naming and Location</h3> |
| 61 | <p>Most CTS test cases target a specific class in the Android API. These tests |
| 62 | have Java package names with a <code>cts</code> suffix and class |
| 63 | names with the <code>Test</code> suffix. Each test case consists of |
| 64 | multiple tests, where each test usually exercises a particular API method of |
| 65 | the API class being tested. These tests are arranged in a directory structure |
| 66 | where tests are grouped into different categories like "widgets" and "views."</p> |
| 67 | <p>For example, the CTS test for <code>android.widget.TextView</code> is |
| 68 | <code>android.widget.cts.TextViewTest</code> found under the |
| 69 | <code>cts/tests/tests/widget/src/android/widget/cts</code> directory with its |
| 70 | Java package name as <code>android.widget.cts</code> and its class name as |
| 71 | <code>TextViewTest</code>. The <code>TextViewTest</code> class has a test called <code>testSetText</code> |
| 72 | that exercises the "setText" method and a test named "testSetSingleLine" that |
| 73 | calls the <code>setSingleLine</code> method. Each of those tests have <code>@TestTargetNew</code> |
| 74 | annotations indicating what they cover.</p> |
| 75 | <p>Some CTS tests do not directly correspond to an API class but are placed in |
| 76 | the most related package possible. For instance, the CTS test, |
| 77 | <code>android.net.cts.ListeningPortsTest</code>, is in the <code>android.net.cts</code>, because it |
| 78 | is network related even though there is no <code>android.net.ListeningPorts</code> class. |
| 79 | You can also create a new test package if necessary. For example, there is an |
| 80 | "android.security" test package for tests related to security. Thus, use your |
| 81 | best judgement when adding new tests and refer to other tests as examples.</p> |
| 82 | <p>Finally, a lot of tests are annotated with @TestTargets and @TestTargetNew. |
| 83 | These are no longer necessary so do not annotate new tests with these.</p> |
| 84 | <h3 id="new-test-packages">New Test Packages</h3> |
| 85 | <p>When adding new tests, there may not be an existing directory to place your |
| 86 | test. In that case, refer to the example under <code>cts/tests/tests/example</code> and |
| 87 | create a new directory. Furthermore, make sure to add your new package's |
| 88 | module name from its <code>Android.mk</code> to <code>CTS_COVERAGE_TEST_CASE_LIST</code> in |
| 89 | <code>cts/CtsTestCaseList.mk</code>. This Makefile is used by <code>build/core/tasks/cts.mk</code> |
| 90 | to glue all the tests together to create the final CTS package.</p> |
| 91 | <h3 id="test-stubs-and-utilities">Test Stubs and Utilities</h3> |
| 92 | <p>Some tests use additional infrastructure like separate activities |
| 93 | and various utilities to perform tests. These are located under the |
| 94 | <code>cts/tests/src</code> directory. These stubs aren't separated into separate test |
| 95 | APKs like the tests, so the <code>cts/tests/src</code> directory does not have additional |
| 96 | top level directories like "widget" or "view." Follow the same principle of |
| 97 | putting new classes into a package with a name that correlates to the purpose |
| 98 | of your new class. For instance, a stub activity used for testing OpenGL like |
| 99 | <code>GLSurfaceViewStubActivity</code> belongs in the <code>android.opengl.cts</code> package under |
| 100 | the <code>cts/tests/src/android/opengl</code> directory.</p> |
| 101 | <h2 id="other-tasks">Other Tasks</h2> |
| 102 | <p>Besides adding new tests there are other ways to contribute to CTS:</p> |
| 103 | <ul> |
| 104 | <li>Fix or remove tests annotated with BrokenTest and KnownFailure.</li> |
| 105 | </ul> |
| 106 | <h2 id="submitting-your-changes">Submitting Your Changes</h2> |
Clay Murphy | a69844e | 2013-05-30 17:56:38 -0700 | [diff] [blame] | 107 | <p>Follow the <a href="{@docRoot}source/submit-patches.html">Android Contributors' Workflow</a> |
Robert Ly | 35f2fda | 2013-01-29 16:27:05 -0800 | [diff] [blame] | 108 | to contribute changes to CTS. A reviewer |
| 109 | will be assigned to your change, and your change should be reviewed shortly!</p> |