Điều quan trọng cần xem xét trong khi viết bài kiểm tra là các đơn vị trách nhiệm xuất hiện khi bạn thiết kế tính năng mới. Kiểm tra đơn vị phải bao gồm tất cả các tương tác có thể có với đơn vị bao gồm các tương tác tiêu chuẩn và các tình huống đặc biệt.

Trong bài viết này chúng tôi sẽ đề cập đến các nguyên tắc cơ bản của thử nghiệm và các khung như Mockito và Espresso mà các nhà phát triển có thể sử dụng để viết các bài kiểm tra đơn vị. 

Tôi cũng sẽ thảo luận ngắn gọn về cách viết mã thử nghiệm. Tôi cũng sẽ giải thích cách bắt đầu với các bài kiểm tra cục bộ và cụ trong ứng dụng Học lập trình Android.

Cải thiện phạm vi cho ứng dụng Android
 

Đề nghị đọc : Cách thiết lập hệ thống kiểm tra tự động bằng điện thoại Android nghiên cứu điều chỉnh.

Nguyên tắc cơ bản của kiểm tra

Một bài kiểm tra đơn vị điển hình có ba giai đoạn.

1. Đầu tiên kiểm tra đơn vị khởi tạo một phần nhỏ của ứng dụng mà nó muốn kiểm tra.
2. Sau đó nó áp dụng một số kích thích cho hệ thống đang được thử nghiệm thường bằng cách gọi một phương thức trên nó.
3. Cuối cùng nó quan sát hành vi kết quả.

Nếu hành vi quan sát phù hợp với mong đợi bài kiểm tra đơn vị vượt qua; mặt khác nó không thành công chỉ ra rằng có một vấn đề ở đâu đó trong hệ thống đang được thử nghiệm. Những giai đoạn thử nghiệm ba đơn vị cũng được biết đến như một rrange  một ct và một ssert  hoặc đơn giản là AAA. Ứng dụng lý tưởng nên bao gồm ba loại thử nghiệm: nhỏ vừa và lớn.

• Các thử nghiệm nhỏ bao gồm các thử nghiệm đơn vị chế nhạo mọi thành phần chính và chạy nhanh trong sự cô lập.
• Kiểm tra trung bình là kiểm tra tích hợp tích hợp một số thành phần và chạy trên trình giả lập hoặc thiết bị thực.
• Các thử nghiệm lớn là các thử nghiệm tích hợp và UI chạy bằng cách hoàn thành quy trình công việc UI và đảm bảo rằng các tác vụ chính của người dùng cuối hoạt động như mong đợi.

Lưu ý: Một bài kiểm tra thiết bị là một loại kiểm tra tích hợp. Đây là những thử nghiệm chạy trên thiết bị Android hoặc trình giả lập. Các thử nghiệm này có quyền truy cập vào thông tin thiết bị chẳng hạn như bối cảnh của ứng dụng đang được thử nghiệm. Sử dụng phương pháp này để chạy thử nghiệm đơn vị có phụ thuộc ứng dụng Học lập trình Android mà các đối tượng giả có thể dễ dàng đáp ứng.

>> Học lập trình ứng dụng Android đang được rất nhiều các bạn trẻ mới ra trường lựa chọn để học Không phải nó dễ học mà nó là con đường gần nhất để đưa các bạn đến với công việc. Bạn đã sẵn sàng trang bị ngay cho mình một khóa học hay chưa thì bấm ngày vào đăng ký nhé nhanh tay đăng ký vì số lượng học bổng có hạn : Học lập trình Android Tại NIIT - ICT Hà Nội <<
 

Viết các bài kiểm tra nhỏ cho phép bạn giải quyết các thất bại một cách nhanh chóng nhưng thật khó để có được sự tự tin rằng một bài kiểm tra vượt qua sẽ cho phép ứng dụng của bạn hoạt động. 

Điều quan trọng là phải kiểm tra từ tất cả các danh mục trong ứng dụng, mặc dù tỷ lệ của từng danh mục có thể khác nhau tùy theo ứng dụng. Một bài kiểm tra đơn vị tốt phải dễ viết dễ đọc đáng tin cậy và nhanh chóng .

Dưới đây là một giới thiệu ngắn gọn về Mockito và Espresso giúp thử nghiệm các ứng dụng Android dễ dàng hơn.

MOCKITO

Có nhiều khung mô phỏng khác nhau nhưng phổ biến nhất trong số đó là mockito :

Mockito là một khuôn khổ chế giễu có vị rất ngon. Nó cho phép bạn viết các bài kiểm tra đẹp với API sạch & đơn giản. Mockito không cung cấp cho bạn nôn nao vì các bài kiểm tra rất dễ đọc và chúng tạo ra các lỗi xác minh sạch.

API thông thạo của nó tách biệt chuẩn bị trước thử nghiệm với xác nhận sau thử nghiệm. Nếu thử nghiệm thất bại, Mockito nói rõ rằng kỳ vọng của chúng ta khác với thực tế ở đâu! Thư viện có mọi thứ bạn cần để viết bài kiểm tra hoàn chỉnh.

CÀ PHÊ ESPRESSO

Espresso giúp bạn viết các bài kiểm tra giao diện người dùng Android ngắn gọn đẹp và đáng tin cậy.

Đoạn mã dưới đây cho thấy một ví dụ về thử nghiệm Espresso. Chúng ta sẽ đưa ra ví dụ tương tự sau trong hướng dẫn này khi chúng ta nói chi tiết về các bài kiểm tra thiết bị.

@Test
public void setUserName() {
    onView(withId(R.id.name_field)).perform(typeText("Vivek Maskara"));
    onView(withId(R.id.set_user_name)).perform(click());
    onView(withText("Hello Vivek Maskara!")).check(matches(isDisplayed()));
}

Espresso kiểm tra các kỳ vọng tương tác và xác nhận rõ ràng không làm xáo trộn nội dung nồi hơi cơ sở hạ tầng tùy chỉnh hoặc chi tiết triển khai lộn xộn. Bất cứ khi nào thử nghiệm của bạn gọi onView() Espresso sẽ chờ để thực hiện hành động UI hoặc xác nhận tương ứng cho đến khi các điều kiện đồng bộ hóa được đáp ứng nghĩa là:

• hàng đợi tin nhắn trống
• không có trường hợp AsyncTasknào đang thực hiện một nhiệm vụ,
• các tài nguyên nhàn rỗi là nhàn rỗi.

Những kiểm tra này đảm bảo rằng kết quả kiểm tra là đáng tin cậy.

Viết mã kiểm tra

Đơn vị thử nghiệm ứng dụng Android là khó khăn và đôi khi không thể. Một thiết kế tốt và chỉ một thiết kế tốt có thể làm cho thử nghiệm đơn vị dễ dàng hơn. Dưới đây là một số khái niệm quan trọng để viết mã có thể kiểm tra.

Tránh trộn lẫm  xây dựng đồ thị đối tượng Logic ứng dụng

Trong một bài kiểm tra, bạn muốn khởi tạo lớp đang kiểm tra và áp dụng một số kích thích cho lớp và khẳng định rằng hành vi dự kiến ​​đã được quan sát. Đảm bảo rằng lớp được kiểm tra không khởi tạo các đối tượng khác và các đối tượng đó không khởi tạo thêm các đối tượng v.v. Để có cơ sở mã có thể kiểm tra ứng dụng của bạn cần có hai loại lớp:

• Các nhà máy, có đầy đủ các nhà khai thác mới, có trách nhiệm xây dựng biểu đồ đối tượng cho ứng dụng của bạn;
• Các lớp logic ứng dụng, không có toán tử mới của nhà điều hành và có trách nhiệm thực hiện công việc.

Người xây dựng không làm bất cứ một việc gì

Hoạt động phổ biến nhất bạn sẽ làm trong các bài kiểm tra là khởi tạo đồ thị đối tượng. Vì vậy, làm cho nó dễ dàng với chính bạn và làm cho các nhà xây dựng không làm việc gì ngoài việc gán tất cả các phụ thuộc vào các trường. Làm việc trong hàm tạo không chỉ ảnh hưởng đến các bài kiểm tra trực tiếp của lớp mà còn ảnh hưởng đến các bài kiểm tra liên quan cố gắng khởi tạo lớp của bạn một cách gián tiếp.

Tránh các phương phát tĩnh bất cứ nơi nào có thể

Chìa khóa để kiểm tra là sự hiện diện của những nơi mà bạn có thể chuyển hướng luồng thực thi bình thường. Đường may là cần thiết để bạn có thể cô lập đơn vị thử nghiệm. 

Nếu bạn xây dựng một ứng dụng không có gì ngoài các phương thức tĩnh bạn sẽ có một ứng dụng thủ tục. Một phương thức tĩnh sẽ ảnh hưởng như thế nào từ quan điểm kiểm tra phụ thuộc vào vị trí của nó trong biểu đồ cuộc gọi ứng dụng của bạn. 

Một phương thức lá như Math.abs() không phải là một vấn đề vì biểu đồ cuộc gọi thực hiện kết thúc ở đó. Nhưng nếu bạn chọn một phương thức trong lõi của logic ứng dụng của mình thì mọi thứ đằng sau phương thức đó sẽ trở nên khó kiểm tra bởi vì không có cách nào để chèn kiểm tra nhân đôi  

Tránh trộn lẫn các những mối quan tâm 

Một lớp nên chịu trách nhiệm đối phó với chỉ một thực thể. Trong một lớp học một phương thức nên có trách nhiệm thực hiện chỉ một việc. Ví dụ BusinessService nên có trách nhiệm chỉ nói chuyện với a Business và không BusinessReceipts. 

Hơn nữa một phương thức trong BusinessServicecó thể là getBusinessProfile, nhưng một phương pháp như createAndGetBusinessProfile sẽ không lý tưởng để thử nghiệm. S OLID nguyên tắc thiết kế phải được tuân thủ cho thiết kế tốt:

• S : nguyên tắc đơn trách nhiệm;
• O : nguyên tắc đóng mở;
• L : Nguyên tắc thay thế Liskov;
• I : nguyên tắc phân tách giao diện;
• D : nguyên tắc đảo ngược phụ thuộc.

Trong vài phần tiếp theo, chúng tôi sẽ sử dụng các ví dụ từ một ứng dụng thực sự đơn giản mà tôi đã xây dựng cho hướng dẫn này. Ứng dụng này có một EditText tên người dùng làm đầu vào và hiển thị tên đó TextView khi nhấp vào nút. Vui lòng lấy mã nguồn hoàn chỉnh cho dự án từ GitHub. Đây là một ảnh chụp màn hình của ứng dụng:

Viết bài kiểm tra đơn vị địa phương

Kiểm tra đơn vị có thể được chạy cục bộ trên máy phát triển của bạn mà không cần thiết bị hoặc trình giả lập. Phương pháp thử nghiệm này hiệu quả vì nó tránh được chi phí phải tải ứng dụng đích và mã kiểm tra đơn vị vào thiết bị vật lý hoặc trình giả lập mỗi khi chạy thử nghiệm của bạn.

Ngoài Mockito bạn cũng sẽ cần định cấu hình các phụ thuộc kiểm tra cho dự án của mình để sử dụng các API tiêu chuẩn được cung cấp bởi khung JUnit 4.

Thiết lập môi trường phát triển

Bắt đầu bằng cách thêm một phụ thuộc vào JUnit4 trong dự án của bạn. Sự phụ thuộc thuộc loại testImplementation có nghĩa là các phụ thuộc chỉ được yêu cầu để biên dịch nguồn thử nghiệm của dự án.

testImplementation 'junit:junit:4.12'

Chúng tôi cũng sẽ cần thư viện Mockito để giúp tương tác với các phụ thuộc Android dễ dàng hơn.

testImplementation "org.mockito:mockito-core:$MOCKITO_VERSION"

Đảm bảo đồng bộ hóa dự án sau khi thêm phụ thuộc. Android Studio nên tạo cấu trúc thư mục để kiểm tra đơn vị theo mặc định. Nếu không, đảm bảo cấu trúc thư mục sau tồn tại:

<Project Dir>/app/src/test/java/com/maskaravivek/testingExamples

Tạo bài kiểm tra đơn vị đầu tiên của bạn

Giả sử bạn muốn kiểm tra displayUserName chức năng trong UserService. Để đơn giản hàm chỉ định dạng đầu vào và trả về. Trong một ứng dụng trong thế giới thực nó có thể thực hiện cuộc gọi mạng để tìm nạp hồ sơ người dùng và trả lại tên người dùng.

@Singleton
class UserService @Inject
constructor(private var context: Context) {
    
    fun displayUserName(name: String): String {
        val userNameFormat = context.getString(R.string.display_user_name)
        return String.format(Locale.ENGLISH, userNameFormat, name)
    }
}

Chúng tôi sẽ bắt đầu bằng cách tạo một UserServiceTest lớp trong thư mục thử nghiệm của chúng tôi. Các UserService sử dụng lớp Context mà cần phải được chế giễu với mục đích thử nghiệm. Mockito cung cấp một Mock ký hiệu cho các đối tượng chế giễu có thể được sử dụng như sau:

@Mock internal var context: Context? = null

Tương tự bạn sẽ cần phải chế nhạo tất cả các phụ thuộc cần thiết để xây dựng thể hiện của UserService lớp. Trước khi thử nghiệm, bạn sẽ cần khởi tạo các giả này và đưa chúng vào UserService lớp.

• @InjectMock tạo một thể hiện của lớp và đưa các giả được đánh dấu bằng các chú thích @Mock vào nó.
• MockitoAnnotations.initMocks(this); khởi tạo các trường được chú thích bằng chú thích Mockito.

Đây là cách nó có thể được thực hiện:

class UserServiceTest {
    
    @Mock internal var context: Context? = null
    @InjectMocks internal var userService: UserService? = null
    
    @Before
    fun setup() {
        MockitoAnnotations.initMocks(this)
    }
}

Bây giờ bạn đã hoàn thành việc thiết lập lớp kiểm tra của bạn. Hãy thêm một bài kiểm tra vào lớp này để xác minh chức năng của display User Name hàm. Đây là những gì bài kiểm tra trông như thế nào:

@Test
fun displayUserName() {
    doReturn("Hello %s!").`when`(context)!!.getString(any(Int::class.java))
    val displayUserName = userService!!.displayUserName("Test")
    assertEquals(displayUserName, "Hello Test!")
}