Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

Nhắm mục tiêu một ví dụ ứng dụng

Danh mục kiểm tra thiết bị đo này không khác với những loại nhắm mục tiêu đến các ứng dụng Android thông thường. Cần lưu ý rằng ứng dụng thử nghiệm bao gồm thiết bị đo đạc cần phải được ký bằng cùng một chứng chỉ với ứng dụng mà nó đang nhắm mục tiêu.

Lưu ý rằng hướng dẫn này giả định rằng bạn đã có một số kiến ​​thức về quy trình làm việc của cây nguồn nền tảng. Nếu không, vui lòng tham khảo https://source.android.com/source/requirements. Ví dụ được đề cập ở đây là viết một bài kiểm tra thiết bị đo mới với gói mục tiêu được đặt tại gói ứng dụng kiểm tra của chính nó. Nếu bạn không quen với các khái niệm, vui lòng đọc qua giới thiệu thử nghiệm nền tảng .

Hướng dẫn này sử dụng bài kiểm tra sau để làm mẫu:

  • framework / base / package / Shell / tests

Bạn nên duyệt qua mã trước để có ấn tượng sơ bộ trước khi tiếp tục.

Quyết định vị trí nguồn

Bởi vì xét nghiệm đo đạc sẽ được nhắm mục tiêu một ứng dụng, quy ước là đặt mã nguồn thử nghiệm trong một tests thư mục dưới thư mục gốc của thư mục nguồn thành phần của bạn trong cây nền tảng nguồn.

Xem thêm các cuộc thảo luận về vị trí nguồn trong ví dụ end-to-end cho các bài kiểm tra tự instrumenting .

Tệp kê khai

Cũng giống như một ứng dụng thông thường, mỗi mô-đun kiểm tra thiết bị đo đạc cần có một tệp kê khai. Nếu bạn đặt tên cho tập tin như AndroidManifest.xml và cung cấp cho nó bên cạnh Android.mk cho tmodule thử nghiệm của bạn, nó sẽ được tự động bao gồm bởi BUILD_PACKAGE makefile lõi.

Trước khi tiếp tục, nó rất khuyến khích để đi qua các ứng dụng Manifest Tổng quan đầu tiên.

Điều này cung cấp tổng quan về các thành phần cơ bản của tệp kê khai và chức năng của chúng.

Bạn có thể truy cập phiên bản mới nhất của tệp kê khai cho thay đổi mẫu vi trùng tại: https://android.googlesource.com/platform/frameworks/base/+/master/packages/Shell/tests/AndroidManifest.xml

Một ảnh chụp nhanh được bao gồm ở đây để thuận tiện:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

    <application>
        <uses-library android:name="android.test.runner" />

        <activity
            android:name="com.android.shell.ActionSendMultipleConsumerActivity"
            android:label="ActionSendMultipleConsumer"
            android:theme="@android:style/Theme.NoDisplay"
            android:noHistory="true"
            android:excludeFromRecents="true">
            <intent-filter>
                <action android:name="android.intent.action.SEND_MULTIPLE" />
                <category android:name="android.intent.category.DEFAULT" />
                <data android:mimeType="*/*" />
            </intent-filter>
        </activity>
    </application>

    <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
        android:targetPackage="com.android.shell"
        android:label="Tests for Shell" />

</manifest>

Một số nhận xét chọn lọc trên tệp kê khai:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

Các package thuộc tính là tên gói ứng dụng: đây là định danh duy nhất mà Android sử dụng khung ứng dụng để xác định một ứng dụng (hoặc trong bối cảnh này: ứng dụng thử nghiệm của bạn). Mỗi người dùng trong hệ thống chỉ có thể cài đặt một ứng dụng với tên gói đó.

Do đây là một gói phần mềm ứng dụng thử nghiệm, độc lập với các gói ứng dụng dưới kiểm tra, tên gói khác phải được sử dụng: một quy ước chung là thêm một hậu tố .test .

Hơn nữa, điều này package thuộc tính là giống như những gì ComponentName#getPackageName() trả về, và cũng giống nhau bạn sẽ sử dụng để tương tác với nhiều pm lệnh phụ qua adb shell .

Cũng xin lưu ý rằng mặc dù tên gói thường có cùng kiểu với tên gói Java, nhưng nó thực sự có rất ít thứ liên quan đến nó. Nói cách khác, gói ứng dụng (hoặc gói thử nghiệm) của bạn có thể chứa các lớp với bất kỳ tên gói nào, mặc dù vậy, mặt khác, bạn có thể chọn đơn giản và có tên gói Java cấp cao nhất trong ứng dụng của bạn hoặc thử nghiệm trùng với tên gói ứng dụng.

<uses-library android:name="android.test.runner" />

Điều này là bắt buộc đối với tất cả các bài kiểm tra Instrumentation vì các lớp liên quan được đóng gói trong một tệp thư viện jar khuôn khổ riêng biệt, do đó yêu cầu các mục nhập classpath bổ sung khi gói kiểm tra được gọi bởi khuôn khổ ứng dụng.

android:targetPackage="com.android.shell"

Điều này đặt các gói Mục tiêu của thiết bị đo đạc để com.android.shell . Khi thiết bị đo đạc được gọi thông qua am instrument lệnh, khởi động lại khuôn khổ com.android.shell quá trình, thiết bị đo đạc và mã tiêm vào quá trình để thực hiện thử nghiệm. Điều này cũng có nghĩa là mã kiểm tra sẽ có quyền truy cập vào tất cả các phiên bản lớp đang chạy trong ứng dụng đang được kiểm tra và có thể thao tác trạng thái tùy thuộc vào các móc kiểm tra được hiển thị.

Tệp cấu hình đơn giản

Mỗi mô-đun thử nghiệm mới phải có tệp cấu hình để chỉ đạo hệ thống xây dựng với siêu dữ liệu mô-đun, phụ thuộc thời gian biên dịch và hướng dẫn đóng gói. Trong hầu hết các trường hợp, tùy chọn tệp Blueprint dựa trên Soong là đủ. Xem Cấu hình thử nghiệm đơn giản để biết chi tiết.

Tệp cấu hình phức tạp

Đối với các xét nghiệm phức tạp hơn, bạn cũng cần phải viết một tập tin cấu hình thử nghiệm cho khai thác thử nghiệm của Android, Liên đoàn thương mại .

Cấu hình thử nghiệm có thể chỉ định các tùy chọn thiết lập thiết bị đặc biệt và các đối số mặc định để cung cấp cho lớp thử nghiệm.

Phiên bản mới nhất của tập tin cấu hình cho sự thay đổi Gerrit mẫu có thể được truy cập tại địa chỉ: khung / cơ sở / gói / Shell / kiểm tra / AndroidTest.xml

Một ảnh chụp nhanh được bao gồm ở đây để thuận tiện:

<configuration description="Runs Tests for Shell.">
    <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
        <option name="test-file-name" value="ShellTests.apk" />
    </target_preparer>

    <option name="test-suite-tag" value="apct" />
    <option name="test-tag" value="ShellTests" />
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="com.android.shell.tests" />
        <option name="runner" value="android.support.test.runner.AndroidJUnitRunner" />
    </test>
</configuration>

Một số nhận xét chọn lọc trên tệp cấu hình thử nghiệm:

<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
  <option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>

Điều này yêu cầu Trade Federation cài đặt ShellTests.apk vào thiết bị đích bằng target_preparer được chỉ định. Có nhiều trình chuẩn bị mục tiêu có sẵn cho các nhà phát triển trong Trade Federation và chúng có thể được sử dụng để đảm bảo thiết bị được thiết lập đúng cách trước khi thực hiện thử nghiệm.

<test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="com.android.shell.tests"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>

Điều này chỉ định lớp thử nghiệm của Trade Federation để sử dụng để thực hiện thử nghiệm và vượt qua trong gói trên thiết bị được thực hiện và khung chạy thử nghiệm là JUnit trong trường hợp này.

Nhìn vào đây để biết thêm thông tin về thử nghiệm module Configs

Các tính năng của JUnit4

Sử dụng android-support-test thư viện như Á hậu thử nghiệm cho phép adoptation của lớp học thử nghiệm phong cách Junit4 mới, và sự thay đổi Gerrit mẫu chứa một số sử dụng rất cơ bản tính năng của nó.

Mã nguồn mới nhất cho sự thay đổi Gerrit mẫu có thể được truy cập tại địa chỉ: khung / cơ sở / gói / Shell / kiểm tra / src / com / android / vỏ / BugreportReceiverTest.java

Mặc dù các mẫu kiểm tra thường dành riêng cho các nhóm thành phần, nhưng có một số mẫu sử dụng thường hữu ích.

@SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {

Một sự khác biệt đáng kể trong JUnit4 là các bài kiểm tra không còn bắt buộc phải kế thừa từ một lớp kiểm tra cơ sở chung nữa; thay vào đó, bạn viết các bài kiểm tra trong các lớp Java thuần túy và sử dụng chú thích để chỉ ra các ràng buộc và thiết lập kiểm tra nhất định. Trong ví dụ này, chúng tôi đang hướng dẫn rằng lớp này nên được chạy dưới dạng thử nghiệm Android JUnit4.

Các @SmallTest chú thích chỉ định một kích thước thử nghiệm cho toàn bộ lớp kiểm tra: tất cả các phương pháp thử nghiệm bổ sung vào lớp thử nghiệm này kế thừa thử nghiệm này kích thước chú thích. trước kiểm tra thiết lập lớp, bài kiểm tra rách xuống, và bài kiểm tra lớp giọt nước mắt xuống: tương tự như setUptearDown phương pháp trong Junit4. Test chú thích được sử dụng để chú thích các thử nghiệm thực tế.

    @Before
    public void setup() {
    ...
    @Test
    public void testGetProvider_shouldCacheProvider() {
    ...

Các @Before chú thích được sử dụng trên các phương pháp bởi Junit4 để thực hiện thiết lập thử nghiệm trước. Mặc dù không được sử dụng trong ví dụ này, cũng có @After cho bài kiểm tra teardown. Tương tự, @BeforeClass@AfterClass chú thích được có thể được sử dụng trên các phương pháp bởi Junit4 để thực hiện thiết lập trước khi thực hiện tất cả các bài kiểm tra trong một lớp học kiểm tra, và teardown sau đó. Lưu ý rằng thiết lập phạm vi lớp và phương thức chia nhỏ phải tĩnh.

Đối với các phương pháp kiểm tra, không giống như trong phiên bản trước của JUnit, họ cần có thời gian khởi động tên phương pháp với test , thay vào đó, mỗi người trong số họ phải được chú thích với @Test . Như thường lệ, các phương thức kiểm tra phải công khai, không khai báo giá trị trả về, không nhận tham số và có thể đưa ra các ngoại lệ.

        Context context = InstrumentationRegistry.getTargetContext();

Bởi vì Junit4 xét nghiệm không còn đòi hỏi một lớp cơ sở chung, nó không còn cần thiết để có được Context trường qua getContext() hoặc getTargetContext() thông qua phương pháp lớp cơ sở; thay vào đó, các Á hậu kiểm tra mới quản lý chúng thông qua InstrumentationRegistry nơi thiết lập ngữ cảnh và môi trường tạo ra bởi khuôn khổ thiết bị đo đạc được lưu trữ. Thông qua lớp học này, bạn cũng có thể gọi:

  • getInstrumentation() : thể hiện cho Instrumentation lớp
  • getArguments() : các đối số dòng lệnh truyền cho am instrument qua -e <key> <value>

Xây dựng và thử nghiệm cục bộ

Đối với các trường hợp sử dụng phổ biến nhất, employ Atest .

Đối với trường hợp phức tạp hơn đòi hỏi tùy biến nặng hơn, hãy làm theo các hướng dẫn thiết bị đo đạc .