Nội dung bạn nên kiểm thử phụ thuộc vào các yếu tố như loại ứng dụng, nhóm phát triển, số lượng mã cũ và cấu trúc được sử dụng. Các phần sau đây trình bày những điều mà người mới bắt đầu nên cân nhắc khi lên kế hoạch kiểm thử trong ứng dụng.
Sắp xếp thư mục kiểm thử
Một dự án điển hình trong Android Studio có 2 thư mục lưu giữ các chương trình kiểm thử tuỳ thuộc vào môi trường thực thi. Sắp xếp chương trình kiểm thử theo các thư mục sau như mô tả:
- Thư mục
androidTestphải chứa các bài kiểm thử chạy trên thiết bị thực hoặc thiết bị ảo. Các chương trình kiểm thử như vậy bao gồm kiểm thử tích hợp, kiểm thử toàn diện và các kiểm thử khác mà chỉ riêng JVM không thể xác thực chức năng của ứng dụng. - Thư mục
testphải chứa các chương trình kiểm thử chạy trên máy cục bộ của bạn, chẳng hạn như kiểm thử đơn vị. Khác với những điều nêu trên, đây có thể là các phép kiểm thử chạy trên một JVM cục bộ.
Kiểm thử đơn vị thiết yếu
Khi làm theo phương pháp hay nhất, bạn nên đảm bảo sử dụng kiểm thử đơn vị trong các trường hợp sau:
- Kiểm thử đơn vị cho ViewModels hoặc người trình bày.
- Kiểm thử đơn vị cho lớp dữ liệu, đặc biệt là kho lưu trữ. Hầu hết lớp dữ liệu phải độc lập với nền tảng. Làm như vậy cho phép kiểm thử kép để thay thế mô-đun cơ sở dữ liệu và nguồn dữ liệu từ xa trong kiểm thử. Xem hướng dẫn về cách sử dụng kỹ thuật nhân đôi kiểm thử trong Android
- Kiểm thử đơn vị cho các lớp không phụ thuộc vào nền tảng khác, chẳng hạn như lớp Miền, như với các trường hợp sử dụng và trình tương tác.
- Kiểm thử đơn vị cho các lớp tiện ích, chẳng hạn như thao tác trên chuỗi và toán học.
Kiểm thử các trường hợp hiếm gặp
Kiểm thử đơn vị nên tập trung vào cả trường hợp thông thường và trường hợp hiếm gặp. Trường hợp hiếm gặp là các trường hợp không phổ biến mà người kiểm thử và các bài kiểm thử lớn hơn khó có thể phát hiện được. Có thể kể đến một số ví dụ như sau:
- Các phép toán sử dụng số âm, 0 và điều kiện giới hạn.
- Tất cả lỗi kết nối mạng có thể xảy ra.
- Dữ liệu bị hỏng, chẳng hạn như JSON không đúng định dạng.
- Mô phỏng bộ nhớ đầy khi lưu vào tệp.
- Đối tượng được tạo lại khi đang thực hiện quy trình (chẳng hạn như một hoạt động khi thiết bị được xoay).
Các phép kiểm thử đơn vị cần tránh
Bạn nên tránh một số kiểm thử đơn vị vì có giá trị thấp:
- Các chương trình kiểm thử xác minh hoạt động chính xác của khung hoặc thư viện chứ không phải mã của bạn.
- Các điểm truy cập khung như hoạt động, mảnh hoặc dịch vụ không được có logic nghiệp vụ, vì vậy, bạn không nên ưu tiên kiểm thử đơn vị. Các bài kiểm thử đơn vị cho hoạt động có ít giá trị vì các bài kiểm thử này chủ yếu bao gồm mã khung và đòi hỏi việc thiết lập nhiều hơn. Các hoạt động kiểm thử đo lường như kiểm thử giao diện người dùng có thể bao gồm các lớp này.
Kiểm thử giao diện người dùng
Bạn nên triển khai một số loại kiểm thử giao diện người dùng:
- Kiểm thử giao diện người dùng trên màn hình kiểm tra các hoạt động tương tác quan trọng của người dùng trong một màn hình. Chúng thực hiện các thao tác như nhấp vào nút, nhập biểu mẫu và kiểm tra trạng thái hiển thị. Bạn nên bắt đầu bằng một lớp kiểm thử cho mỗi màn hình.
- Kiểm thử luồng người dùng hoặc Kiểm thử điều hướng, bao gồm các đường dẫn phổ biến nhất. Các chương trình kiểm thử này mô phỏng một người dùng di chuyển qua một quy trình điều hướng. Đây là các phép kiểm thử đơn giản, hữu ích trong việc kiểm tra các sự cố thời gian chạy khi khởi chạy.
Các cảnh báo thử nghiệm khác
Có nhiều loại hình kiểm thử chuyên biệt hơn như kiểm thử ảnh chụp màn hình, kiểm thử hiệu suất và kiểm thử khỉ. Bạn cũng có thể phân loại các bài kiểm thử theo mục đích, chẳng hạn như hồi quy, khả năng hỗ trợ tiếp cận và khả năng tương thích.
Tài liệu đọc thêm
Để kiểm thử riêng biệt, thông thường, bạn cần thay thế các phần phụ thuộc của đối tượng đang kiểm thử bằng các phần phụ thuộc giả mạo hoặc mô phỏng, được gọi là "Nhân đôi kiểm thử". Hãy tiếp tục đọc về chúng trong phần Sử dụng nhân đôi kiểm thử trong Android.
Nếu bạn muốn tìm hiểu cách tạo chương trình kiểm thử đơn vị và giao diện người dùng, hãy xem bài viết Lớp học lập trình kiểm thử.