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

Danh mục kiểm tra thiết bị này không khác mấy so với danh mục kiểm tra các ứng dụng Android thông thường. Cần lưu ý rằng ứng dụng thử nghiệm có chứa thiết bị đo đạc cần phải được ký bằng cùng chứng chỉ với ứng dụng mà nó 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 Yêu cầu . Ví dụ được đề cập ở đây là viết một bài kiểm thử thiết bị đo đạc mới với gói mục tiêu được đặt ở gói ứng dụng kiểm thử riêng của nó. Nếu bạn chưa quen với khái niệm này, vui lòng đọc qua phần giới thiệu về 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:

  • khung/cơ sở/gói/Shell/kiểm tra

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

Vì kiểm thử thiết bị sẽ nhắm mục tiêu một ứng dụng nên quy ước là đặt mã nguồn kiểm thử vào thư mục tests dưới thư mục gốc của thư mục nguồn thành phần trong cây nguồn nền tảng.

Xem thêm các cuộc thảo luận về vị trí nguồn trong ví dụ tổng thể về các bài kiểm tra tự thiết bị .

Tệp kê khai

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 tệp là AndroidManifest.xml và đặt nó bên cạnh Android.mk cho mô-đun thử nghiệm của mình, thì tệp này sẽ tự động được đưa vào bởi tệp tạo lõi BUILD_PACKAGE .

Trước khi tiếp tục, bạn nên xem qua Tổng quan về bản kê khai ứng dụng trước.

Phần này cung cấp thông tin 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 gerrit mẫu tại: https://android.googlesource.com/platform/frameworks/base/+/main/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">

Thuộc tính package là tên gói ứng dụng: đây là mã định danh duy nhất mà khung ứng dụng Android sử dụng để xác định một ứng dụng (hoặc trong ngữ 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 cài đặt một ứng dụng có tên gói đó.

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

Hơn nữa, thuộc tính package này giống với thuộc tính mà ComponentName#getPackageName() trả về và cũng giống như thuộc tính bạn sẽ sử dụng để tương tác với các lệnh phụ pm khác nhau thông 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 thực tế nó có rất ít điều liên quan đến tên đó. Nói cách khác, gói ứng dụng (hoặc thử nghiệm) của bạn có thể chứa các lớp có bất kỳ tên gói nào, mặc dù mặt khác, bạn có thể chọn sự đơn giản và có tên gói Java cấp cao nhất trong ứng dụng hoặc thử nghiệm của mình giống hệt 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 thử nghiệm Thiết bị vì các lớp liên quan được đóng gói trong một tệp thư viện khung jar riêng biệt, do đó yêu cầu các mục nhập đường dẫn lớp bổ sung khi khung ứng dụng gọi gói thử nghiệm.

android:targetPackage="com.android.shell"

Điều này đặt gói mục tiêu của thiết bị đo đạc thành com.android.shell . Khi thiết bị được gọi thông qua lệnh am instrument , khung sẽ khởi động lại quy trình com.android.shell và đưa mã thiết bị vào quy trình để thực hiện kiểm tra. Đ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 móc kiểm tra được hiển thị.

Tập tin 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 để điều khiển hệ thống xây dựng bằng siêu dữ liệu mô-đun, các phần phụ thuộc tại thời điểm 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 thử nghiệm phức tạp hơn, bạn cũng cần viết tệp cấu hình thử nghiệm cho khai thác thử nghiệm của Android, Trade Union .

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.

Bạn có thể truy cập phiên bản mới nhất của tệp cấu hình cho thay đổi gerrit mẫu tại: frameworks/base/packages/Shell/tests/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 file 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 Liên đoàn Thương mại cài đặt ShellTests.apk vào thiết bị mục tiêu bằng cách sử dụng target_preparer được chỉ định. Có nhiều công cụ chuẩn bị mục tiêu dành cho các nhà phát triển trong Liên đoàn Thương mại và những công cụ này 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 kiểm thử của Liên đoàn Thương mại sẽ sử dụng để thực hiện kiểm thử và chuyển gói trên thiết bị sẽ được thực thi và khung chạy kiểm thử là JUnit trong trường hợp này.

Xem tại đây để biết thêm thông tin về Cấu hình mô-đun thử nghiệm

Tính năng JUnit4

Việc sử dụng thư viện android-support-test làm trình chạy thử cho phép áp dụng các lớp kiểm tra kiểu JUnit4 mới và thay đổi gerrit mẫu chứa một số cách sử dụng rất cơ bản các tính năng của nó.

Bạn có thể truy cập mã nguồn mới nhất cho thay đổi gerrit mẫu tại: frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java

Mặc dù các mẫu thử nghiệm 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 cần thiết 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 đơn giản 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 hướng dẫn rằng lớp này nên được chạy dưới dạng thử nghiệm Android JUnit4.

Chú thích @SmallTest đã chỉ định kích thước kiểm tra cho toàn bộ lớp kiểm tra: tất cả các phương pháp kiểm tra được thêm vào lớp kiểm tra này đều kế thừa chú thích kích thước kiểm tra này. thiết lập lớp kiểm tra trước, phân tách sau kiểm tra và phân tách lớp sau kiểm tra: tương tự như các phương thức setUptearDown trong JUnit4. Chú thích Test được sử dụng để chú thích bài kiểm tra thực tế.

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

Chú thích @Before được JUnit4 sử dụng trên các phương thức để 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 nhưng cũng có @After để phân tích bài kiểm tra sau. Tương tự, các chú thích @BeforeClass@AfterClass có thể được JUnit4 sử dụng trên các phương thức để thực hiện thiết lập trước khi thực hiện tất cả các thử nghiệm trong một lớp thử nghiệm và phân tích sau đó. Lưu ý rằng các phương thức thiết lập và phân chia phạm vi lớp phải ở trạng thái tĩnh.

Đối với các phương thức thử nghiệm, không giống như phiên bản JUnit trước đó, chúng không còn cần bắt đầu tên phương thức bằng test , thay vào đó, mỗi phương thức phải được chú thích bằng @Test . Như thường lệ, các phương thức thử nghiệm 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 ngoại lệ.

        Context context = InstrumentationRegistry.getTargetContext();

Bởi vì các bài kiểm tra JUnit4 không còn yêu cầu một lớp cơ sở chung nữa nên không cần thiết phải lấy các cá thể Context thông qua getContext() hoặc getTargetContext() thông qua các phương thức lớp cơ sở nữa; thay vào đó, trình chạy thử nghiệm mới sẽ quản lý chúng thông qua InstrumentationRegistry , nơi lưu trữ thiết lập theo ngữ cảnh và môi trường do khung công cụ đo lường tạo ra. Thông qua lớp này, bạn cũng có thể gọi:

  • getInstrumentation() : phiên bản của lớp Instrumentation
  • getArguments() : các đối số dòng lệnh được truyền tới am instrument thông qua -e <key> <value>

Xây dựng và thử nghiệm tại địa phương

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

Đối với các trường hợp phức tạp hơn yêu cầu tùy chỉnh nhiều hơn, hãy làm theo hướng dẫn về thiết bị đo đạc .