1 page.title=CTS Development 2 doc.type=compatibility 3 @jd:body 4 5 <h3>Initializing Your Repo Client</h3> 6 7 <p>Follow the 8 <a href="{@docRoot}source/download.html">instructions</a> 9 to get and build the Android source code but specify "-b froyo" 10 when issuing the "repo init" command. This assures that your CTS 11 changes will be included in the next CTS release and beyond.</p> 12 13 <h3>Setting Up Eclipse</h3> 14 15 <p>Follow the 16 <a href="{@docRoot}source/using-eclipse.html">instructions</a> 17 to setup Eclipse but execute the following command to generate the 18 .classpath file rather than copying the one from the development 19 project:</p> 20 21 <pre> 22 cd /path/to/android/root 23 ./cts/development/ide/eclipse/genclasspath.sh > .classpath 24 chmod u+w .classpath 25 </pre> 26 27 <p>This .classpath file will contain both the Android framework 28 packages and the CTS packages.</p> 29 30 <h3>Building and Running CTS</h3> 31 32 <p>Execute the following commands to build CTS and start the interactive 33 CTS console:</p> 34 35 <pre> 36 cd /path/to/android/root 37 make cts 38 cts 39 </pre> 40 41 <p>Provide arguments to CTS to immediately start executing a test:</p> 42 43 <pre> 44 cts start --plan CTS -p android.os.cts.BuildVersionTest 45 </pre> 46 47 <h3>Writing CTS Tests</h3> 48 49 <p>CTS tests use JUnit and the Android testing APIs. Review the 50 <a href="http://d.android.com/guide/topics/testing/testing_android.html">Testing 51 and Instrumentation</a> tutorial while perusing the existing tests under the 52 "cts/tests/tests" directory. You will see that CTS tests mostly follow the same 53 conventions used in other Android tests.</p> 54 55 <p>Since CTS runs across many production devices, the tests must follow 56 these rules:</p> 57 58 <ul> 59 <li>Must take into account varying screen sizes, orientations, and 60 keyboard layouts.</li> 61 <li>Only use public API methods. In other words, avoid all classes, 62 methods, and fields that are annotated with the "hide" annotation.</li> 63 <li>Avoid relying upon particular view layouts or depend on the 64 dimensions of assets that may not be on some device.</li> 65 <li>Don't rely upon root privileges.</li> 66 </ul> 67 68 <h4>Test Naming and Location</h4> 69 70 <p>Most CTS test cases target a specific class in the Android API. These tests 71 have Java package names with a "cts" suffix like "android.view.cts" and class 72 names with the "Test" suffix like "ViewTest." Each test case consists of 73 multiple tests, where each test usually exercises a particular API method of 74 the API class being tested. Each test is annotated with a @TestTargetNew 75 annotation to indicate what API method is being exercised. These tests are 76 arranged in a directory structure where tests are grouped into different 77 categories like "widgets" and "views."</p> 78 79 <p>For example, the CTS test for "android.widget.TextView" is 80 "android.widget.cts.TextVietTest" found under the 81 "cts/tests/tests/widget/src/android/widget/cts" directory with its 82 Java package name as "android.widget.cts" and its class name as 83 "TextViewTest." The "TextViewTest" class has a test called "testSetText" 84 that exercises the "setText" method and a test named "testSetSingleLine" that 85 calls the "setSingleLine" method. Each of those tests have @TestTargetNew 86 annotations indicating what they cover.</p> 87 88 <p>Some CTS tests do not directly correspond to an API class but are placed in 89 the most related package possible. For instance, the CTS test, 90 "android.net.cts.ListeningPortsTest," is in the "android.net.cts," because it 91 is network related even though there is no "android.net.ListeningPorts" class. 92 Thus, use your best judgement when adding new tests and refer to other tests 93 as examples.</p> 94 95 <h4>New Test Packages</h4> 96 97 <p>When adding new tests, there may not be an existing directory to place your 98 test. In that case, refer to the example under "cts/tests/tests/example" and 99 create a new directory. Furthermore, make sure to add your new package's 100 module name from its Android.mk to "CTS_COVERAGE_TEST_CASE_LIST" in 101 "cts/CtsTestCaseList.mk." This Makefile is used by "build/core/tasks/cts.mk" 102 to glue all the tests together to create the final CTS package.</p> 103 104 <h4>Test Stubs and Utilities</h4> 105 106 <p>Some tests use additional infrastructure like separate activities 107 and various utilities to perform tests. These are located under the 108 "cts/tests/src" directory. These stubs aren't separated into separate test 109 APKs like the tests, so the "cts/tests/src" directory does not have additional 110 top level directories like "widget" or "view." Follow the same principle of 111 putting new classes into a package with a name that correlates to the purpose 112 of your new class. For instance, a stub activity used for testing OpenGL like 113 "GLSurfaceViewStubActivity" belongs in the "android.opengl.cts" package under 114 the "cts/tests/src/android/opengl" directory.</p> 115 116 <h3>Other Tasks</h3> 117 118 <p>Besides adding new tests there are other ways to contribute to CTS:</p> 119 120 <ul> 121 <li>Fix or remove tests annotated with BrokenTest and KnownFailure.</li> 122 </ul> 123 124 <h3>Submitting Your Changes</h3> 125 126 <p>Follow the 127 <a href="{@docRoot}source/submit-patches.html">Android 128 contributors' workflow</a> to contribute changes to CTS. A reviewer 129 will be assigned to your change, and your change should be reviewed shortly!</p> 130 131
