a6db53f077
This matches the current state of the live site. Change-Id: If209bc337d31cf8669e2afb78c9b52e5bbe3cdac
131 lines
5.1 KiB
Plaintext
131 lines
5.1 KiB
Plaintext
page.title=CTS Development
|
|
doc.type=compatibility
|
|
@jd:body
|
|
|
|
<h3>Initializing Your Repo Client</h3>
|
|
|
|
<p>Follow the
|
|
<a href="{@docRoot}source/download.html">instructions</a>
|
|
to get and build the Android source code but specify "-b froyo"
|
|
when issuing the "repo init" command. This assures that your CTS
|
|
changes will be included in the next CTS release and beyond.</p>
|
|
|
|
<h3>Setting Up Eclipse</h3>
|
|
|
|
<p>Follow the
|
|
<a href="{@docRoot}source/using-eclipse.html">instructions</a>
|
|
to setup Eclipse but execute the following command to generate the
|
|
.classpath file rather than copying the one from the development
|
|
project:</p>
|
|
|
|
<pre>
|
|
cd /path/to/android/root
|
|
./cts/development/ide/eclipse/genclasspath.sh > .classpath
|
|
chmod u+w .classpath
|
|
</pre>
|
|
|
|
<p>This .classpath file will contain both the Android framework
|
|
packages and the CTS packages.</p>
|
|
|
|
<h3>Building and Running CTS</h3>
|
|
|
|
<p>Execute the following commands to build CTS and start the interactive
|
|
CTS console:</p>
|
|
|
|
<pre>
|
|
cd /path/to/android/root
|
|
make cts
|
|
cts
|
|
</pre>
|
|
|
|
<p>Provide arguments to CTS to immediately start executing a test:</p>
|
|
|
|
<pre>
|
|
cts start --plan CTS -p android.os.cts.BuildVersionTest
|
|
</pre>
|
|
|
|
<h3>Writing CTS Tests</h3>
|
|
|
|
<p>CTS tests use JUnit and the Android testing APIs. Review the
|
|
<a href="http://d.android.com/guide/topics/testing/testing_android.html">Testing
|
|
and Instrumentation</a> tutorial while perusing the existing tests under the
|
|
"cts/tests/tests" directory. You will see that CTS tests mostly follow the same
|
|
conventions used in other Android tests.</p>
|
|
|
|
<p>Since CTS runs across many production devices, the tests must follow
|
|
these rules:</p>
|
|
|
|
<ul>
|
|
<li>Must take into account varying screen sizes, orientations, and
|
|
keyboard layouts.</li>
|
|
<li>Only use public API methods. In other words, avoid all classes,
|
|
methods, and fields that are annotated with the "hide" annotation.</li>
|
|
<li>Avoid relying upon particular view layouts or depend on the
|
|
dimensions of assets that may not be on some device.</li>
|
|
<li>Don't rely upon root privileges.</li>
|
|
</ul>
|
|
|
|
<h4>Test Naming and Location</h4>
|
|
|
|
<p>Most CTS test cases target a specific class in the Android API. These tests
|
|
have Java package names with a "cts" suffix like "android.view.cts" and class
|
|
names with the "Test" suffix like "ViewTest." Each test case consists of
|
|
multiple tests, where each test usually exercises a particular API method of
|
|
the API class being tested. Each test is annotated with a @TestTargetNew
|
|
annotation to indicate what API method is being exercised. These tests are
|
|
arranged in a directory structure where tests are grouped into different
|
|
categories like "widgets" and "views."</p>
|
|
|
|
<p>For example, the CTS test for "android.widget.TextView" is
|
|
"android.widget.cts.TextVietTest" found under the
|
|
"cts/tests/tests/widget/src/android/widget/cts" directory with its
|
|
Java package name as "android.widget.cts" and its class name as
|
|
"TextViewTest." The "TextViewTest" class has a test called "testSetText"
|
|
that exercises the "setText" method and a test named "testSetSingleLine" that
|
|
calls the "setSingleLine" method. Each of those tests have @TestTargetNew
|
|
annotations indicating what they cover.</p>
|
|
|
|
<p>Some CTS tests do not directly correspond to an API class but are placed in
|
|
the most related package possible. For instance, the CTS test,
|
|
"android.net.cts.ListeningPortsTest," is in the "android.net.cts," because it
|
|
is network related even though there is no "android.net.ListeningPorts" class.
|
|
Thus, use your best judgement when adding new tests and refer to other tests
|
|
as examples.</p>
|
|
|
|
<h4>New Test Packages</h4>
|
|
|
|
<p>When adding new tests, there may not be an existing directory to place your
|
|
test. In that case, refer to the example under "cts/tests/tests/example" and
|
|
create a new directory. Furthermore, make sure to add your new package's
|
|
module name from its Android.mk to "CTS_COVERAGE_TEST_CASE_LIST" in
|
|
"cts/CtsTestCaseList.mk." This Makefile is used by "build/core/tasks/cts.mk"
|
|
to glue all the tests together to create the final CTS package.</p>
|
|
|
|
<h4>Test Stubs and Utilities</h4>
|
|
|
|
<p>Some tests use additional infrastructure like separate activities
|
|
and various utilities to perform tests. These are located under the
|
|
"cts/tests/src" directory. These stubs aren't separated into separate test
|
|
APKs like the tests, so the "cts/tests/src" directory does not have additional
|
|
top level directories like "widget" or "view." Follow the same principle of
|
|
putting new classes into a package with a name that correlates to the purpose
|
|
of your new class. For instance, a stub activity used for testing OpenGL like
|
|
"GLSurfaceViewStubActivity" belongs in the "android.opengl.cts" package under
|
|
the "cts/tests/src/android/opengl" directory.</p>
|
|
|
|
<h3>Other Tasks</h3>
|
|
|
|
<p>Besides adding new tests there are other ways to contribute to CTS:</p>
|
|
|
|
<ul>
|
|
<li>Fix or remove tests annotated with BrokenTest and KnownFailure.</li>
|
|
</ul>
|
|
|
|
<h3>Submitting Your Changes</h3>
|
|
|
|
<p>Follow the
|
|
<a href="{@docRoot}source/submit-patches.html">Android
|
|
contributors' workflow</a> to contribute changes to CTS. A reviewer
|
|
will be assigned to your change, and your change should be reviewed shortly!</p>
|
|
|