Kiểm thử trong phát triển di động: khái niệm, các loại và cách tổ chức

Cấp độ kiểm thử: Unit, Integration, E2E

Kiểm thử đơn vị

Kiểm thử đơn vị là nền tảng của kiểm thử ứng dụng di động. Chúng xác minh đơn vị mã nhỏ nhất — một hàm, phương thức hoặc lớp duy nhất được cách ly khỏi phần còn lại của hệ thống. Trong phát triển di động, kiểm thử đơn vị được viết bằng JUnit (Android) và XCTest (iOS). Một kiểm thử đơn vị tốt phải nhanh, độc lập và có thể lặp lại — nó không phụ thuộc vào mạng, cơ sở dữ liệu hoặc thành phần UI. Để cách ly, người ta sử dụng test double: mock, stub và fake.

Mockito (Java/Kotlin) và MockK (ưu tiên Kotlin) là các thư viện phổ biến để tạo đối tượng mock trên Android. Trên iOS, sử dụng OCMock, Cuckoo hoặc giao thức thủ công. Quy tắc: kiểm thử đơn vị nên bao phủ logic kinh doanh và mô hình dữ liệu. Kiểm thử UI không nên trùng lặp kiểm thử đơn vị — chúng xác minh tương tác của người dùng với giao diện.

Kiểm thử tích hợp

Kiểm thử tích hợp xác minh tương tác giữa các thành phần: kho lưu trữ với cơ sở dữ liệu, ViewModel với dịch vụ API, điều hướng giữa các màn hình. Không giống như kiểm thử đơn vị, kiểm thử tích hợp sử dụng các phụ thuộc thực tế hoặc gần thực tế (ví dụ: cơ sở dữ liệu trong bộ nhớ hoặc máy chủ giả). Robolectric là framework để chạy kiểm thử Android trên JVM mà không cần trình giả lập, tăng tốc kiểm thử tích hợp lên 10 lần.

Kiểm thử ảnh chụp (Golden Tests) là một loại kiểm thử tích hợp đặc biệt so sánh thành phần UI đã kết xuất với hình ảnh tham chiếu (ảnh chụp). Nếu giao diện thay đổi, kiểm thử thất bại — nhà phát triển thấy những gì đã thay đổi. Facebook SnapshotTestCase (iOS) và Shot (Android) là các công cụ phổ biến cho kiểm thử ảnh chụp.

Kiểm thử E2E và UI

Kiểm thử E2E (đầu cuối) xác minh toàn bộ kịch bản người dùng từ đầu đến cuối: khởi chạy ứng dụng, đăng nhập, thực hiện hành động, kiểm tra kết quả. Kiểm thử UI là một tập con của E2E tập trung vào giao diện. Công cụ: Espresso (Android), XCUITest (iOS), Detox (React Native). Kiểm thử E2E chậm nhất, vì vậy chúng được chạy riêng trên CI — thường vào các bản dựng ban đêm.

Công cụ iOS: XCTest và XCUITest

XCTest

XCTest là framework tích hợp của Apple để kiểm thử đơn vị ứng dụng di động. XCTestRunner chạy kiểm thử trên trình giả lập hoặc thiết bị thực. Kiểm thử kế thừa từ XCTestCase, bao gồm setUp và tearDown để chuẩn bị và dọn dẹp. XCTest bao gồm XCTAssert để xác nhận (XCTAssertEqual, XCTAssertNil, XCTAssertTrue) và XCTWaiter để chờ các thao tác bất đồng bộ.

Ví dụ kiểm thử XCTest đơn giản: tạo mô hình User, kiểm tra tính chính xác của khởi tạo, định dạng tên và tính tuổi. Code Coverage trong Xcode hiển thị những dòng mã được bao phủ bởi kiểm thử — mục tiêu cho các dự án thương mại: ít nhất 70–80% bao phủ logic kinh doanh. XCTest được tích hợp với Xcode Server và hệ thống CI thông qua xcodebuild test.

XCUITest

XCUITest là framework của Apple để kiểm thử UI. Nó hoạt động thông qua các định danh trợ năng: XCUIElementQuery tìm nút, trường nhập liệu, bảng theo nhãn, định danh hoặc loại. XCUITest ghi lại chuỗi hành động (ghi/phát lại) và tạo mã kiểm thử. Quan trọng: tất cả các phần tử UI phải có accessibilityIdentifier để kiểm thử hoạt động ổn định.

Công cụ Android: JUnit, Espresso, Robolectric

JUnit và Mockito

JUnit là framework cơ bản để kiểm thử đơn vị ứng dụng di động trên Java/Kotlin. Trên Android, sử dụng JUnit 4 (phiên bản ổn định mới nhất 4.13.2) và JUnit 5 cho các dự án mới. Mockito là thư viện tạo đối tượng mock: when(mock.method()).thenReturn(value) — một mẫu tiêu chuẩn để cách ly lớp được kiểm thử khỏi các phụ thuộc.

Ví dụ kiểm thử JUnit cho Android:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.junit.MockitoJUnitRunner;

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;

@RunWith(MockitoJUnitRunner.class)
public class LoginViewModelTest {

    @Mock
    AuthRepository authRepository;

    @Test
    public void login_emptyEmail_returnsError() {
        LoginViewModel vm = new LoginViewModel(authRepository);
        String result = vm.login("", "password123");
        assertEquals("Email cannot be empty", result);
        verify(authRepository, never()).authenticate(any());
    }
}

Espresso và UI Automator

Espresso là framework của Google cho kiểm thử UI Android. Espresso tự động đồng bộ với luồng UI: onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed())). Espresso dễ viết và ổn định nhờ chờ trạng thái không hoạt động tích hợp. UI Automator là framework cho kiểm thử liên ứng dụng có thể tương tác với các phần tử hệ thống (hộp thoại quyền, bảng thông báo).

Công cụ đa nền tảng: Detox, Appium

Detox cho React Native

Detox là framework E2E hộp xám để kiểm thử ứng dụng di động React Native từ Wix. Detox hoạt động trên cả hai nền tảng từ một cơ sở mã kiểm thử duy nhất, sử dụng Espresso (Android) và XCUITest (iOS) bên trong. Detox tự động chờ ứng dụng ở trạng thái không hoạt động (không có hoạt ảnh, yêu cầu mạng, bộ đếm thời gian) và chỉ sau đó thực hiện hành động tiếp theo.

Appium

Appium là framework đa nền tảng phổ quát hỗ trợ Android, iOS, Web và ứng dụng lai. Appium sử dụng giao thức WebDriver và hỗ trợ bất kỳ ngôn ngữ lập trình nào (Java, Python, JS, Ruby). Máy chủ Appium hoạt động như một máy chủ HTTP dịch các lệnh thành lệnh UI Automator / XCUITest gốc. Nhược điểm chính của Appium là tốc độ: kiểm thử chạy chậm hơn so với Espresso hoặc XCUITest gốc.

TDD và BDD: phương pháp kiểm thử

TDD: Phát triển hướng kiểm thử

TDD là phương pháp kiểm thử ứng dụng di động trong đó kiểm thử được viết trước mã triển khai. Chu kỳ Red-Green-Refactor: (1) viết kiểm thử thất bại (Red), (2) viết mã tối thiểu để vượt qua kiểm thử (Green), (3) tái cấu trúc mã trong khi vẫn đảm bảo kiểm thử vượt qua. TDD cung cấp 100% bao phủ kiểm thử cho chức năng mới và kiến trúc sạch, vì kiểm thử là đặc tả đầu tiên của yêu cầu.

BDD: Phát triển hướng hành vi

BDD là phần mở rộng của TDD trong đó kiểm thử được viết bằng ngôn ngữ tự nhiên theo định dạng Given-When-Then. Given (bối cảnh) — When (hành động) — Then (kết quả mong đợi). Kiểm thử BDD có thể hiểu được đối với tất cả thành viên nhóm: nhà phát triển, người kiểm thử, nhà phân tích và khách hàng. Mock vs Stub vs Fake: Mock xác minh tương tác (phương thức có được gọi không), Stub trả về dữ liệu cố định, Fake là triển khai làm việc đơn giản hóa (ví dụ: DB trong bộ nhớ). Tại IT Sectr, chúng tôi sử dụng TDD cho logic kinh doanh quan trọng và BDD cho các kịch bản chấp nhận.

Test Doubles là tên chung cho các đối tượng thay thế các phụ thuộc thực tế trong kiểm thử. Có bốn loại: Dummy (đối tượng để điền tham số, không được sử dụng), Stub (trả về giá trị đã cho), Spy (ghi lại các lời gọi để xác minh), Mock (xác định trước các lời gọi mong đợi). Hiểu được sự khác biệt là rất quan trọng để thiết kế kiểm thử đúng đắn.

CI/CD và Device Farm

Tự động hóa kiểm thử trong CI/CD

CI/CD — Tích hợp Liên tục và Phân phối Liên tục: thực tiễn tự động xây dựng và kiểm thử ứng dụng di động mỗi khi có thay đổi mã. Trong phát triển di động, đường ống CI/CD bao gồm: linting, kiểm thử đơn vị, kiểm thử tích hợp, xây dựng APK/IPA và kiểm thử UI. GitHub Actions và Bitrise là các nền tảng phổ biến cho CI/CD di động. Kiểm thử nên chạy nhanh: kiểm thử đơn vị trong 1–2 phút, kiểm thử tích hợp trong 5–10, kiểm thử UI trong 15–30 phút.

Device Farm

Device Farm là trang trại thiết bị thực tế để kiểm thử. Firebase Test Lab (Android) và Xcode Cloud (iOS) cung cấp quyền truy cập đám mây đến hàng trăm mẫu thiết bị. Device Farm phát hiện các vấn đề không thấy trên trình giả lập: kích thước màn hình khác nhau, hiệu suất trên thiết bị cũ, vấn đề tương thích. Tại IT Sectr, chúng tôi sử dụng Firebase Test Lab cho Android và Xcode Cloud cho iOS thường xuyên.