Chào mừng các bạn trở lại với loạt bài Android Developer Roadmap! Sau khi đã cùng nhau đi qua các chủ đề từ cơ bản như cú pháp Kotlin, Lập trình Hướng đối tượng (OOP), cấu trúc dữ liệu, đến việc xây dựng UI với Layouts, RecyclerView hay Jetpack Compose, và làm việc với dữ liệu/API (Lưu trữ Dữ liệu, Retrofit), giờ là lúc chúng ta nói về một khía cạnh CỰC KỲ quan trọng để đảm bảo chất lượng và sự ổn định của ứng dụng: **Kiểm thử (Testing)**.
Trong thế giới phát triển phần mềm, việc viết mã hoạt động đúng là chưa đủ. Mã nguồn cần phải đáng tin cậy, dễ bảo trì và có thể mở rộng. Đây là lúc kiểm thử phát huy vai trò của mình. Có nhiều loại kiểm thử khác nhau như kiểm thử đơn vị (Unit Test), kiểm thử tích hợp (Integration Test), kiểm thử UI (UI Test). Trong bài viết này, chúng ta sẽ tập trung vào loại kiểm thử cơ bản và thiết yếu nhất: **Kiểm thử Đơn vị (Unit Testing)** và cách thực hiện nó trong Android sử dụng framework phổ biến: **JUnit**.
Đây sẽ là một bước tiến lớn trong lộ trình của bạn, giúp bạn không chỉ viết code mà còn viết code một cách chuyên nghiệp và có trách nhiệm. Đừng ngần ngại, hãy cùng đi sâu vào thế giới của Unit Testing!
Mục lục
Kiểm thử Đơn vị là gì và Vì sao Nó Quan trọng?
Hãy hình dung ứng dụng Android của bạn giống như một cỗ máy phức tạp được lắp ghép từ hàng ngàn, hàng triệu bộ phận nhỏ. Mỗi bộ phận (unit) có một chức năng cụ thể. Kiểm thử đơn vị là quá trình kiểm tra từng bộ phận nhỏ này một cách độc lập để đảm bảo rằng nó hoạt động đúng như mong đợi.
Trong lập trình, “đơn vị” thường là:
- Một hàm (function)
- Một phương thức (method)
- Một lớp (class) cụ thể
Mục tiêu của kiểm thử đơn vị là cô lập từng “đơn vị” của mã nguồn, cung cấp dữ liệu đầu vào (input) và kiểm tra xem kết quả đầu ra (output) có đúng với kết quả mong đợi hay không. Điều này được thực hiện mà không cần phụ thuộc vào các thành phần khác của hệ thống (như cơ sở dữ liệu, mạng, giao diện người dùng).
Lợi ích của việc viết Unit Test:
- Tìm lỗi sớm: Unit Test giúp phát hiện lỗi ngay trong quá trình phát triển, trước khi chúng lan rộng và trở nên khó sửa hơn. Việc sửa lỗi ở giai đoạn này thường nhanh chóng và ít tốn kém nhất.
- Cải thiện chất lượng thiết kế: Để một lớp hoặc hàm có thể dễ dàng được unit test, nó thường phải được thiết kế sao cho ít phụ thuộc vào các thành phần khác (Loose Coupling) và có một trách nhiệm rõ ràng (Single Responsibility Principle – đã học trong bài Mẫu Thiết kế). Việc nghĩ về cách test code sẽ thúc đẩy bạn viết code “sạch” và dễ bảo trì hơn.
- Tự tin khi Refactor: Khi bạn muốn tối ưu hóa hoặc thay đổi cấu trúc mã nguồn (refactor), bộ Unit Test hiện có sẽ như một “lưới an toàn”. Nếu sau khi refactor mà tất cả các test vẫn pass, bạn có thể khá yên tâm rằng mình chưa làm hỏng chức năng hiện tại.
- Tài liệu sống (Living Documentation): Các test case mô tả rõ ràng hành vi mong đợi của từng đơn vị mã nguồn. Một developer mới tham gia dự án có thể đọc các Unit Test để hiểu nhanh chức năng của một lớp hoặc hàm mà không cần đọc toàn bộ mã nguồn implementation.
- Phản hồi nhanh chóng: Unit Test thường chạy rất nhanh (chỉ trong vài giây hoặc vài phút cho toàn bộ dự án), cho phép bạn kiểm tra sự thay đổi của mình ngay lập tức sau khi viết code. Ngược lại, các loại test khác như UI Test (đã đề cập trong bài Kiểm thử UI với Espresso) thường mất nhiều thời gian hơn để chạy trên thiết bị hoặc giả lập.
Rõ ràng, đầu tư thời gian vào Unit Testing là một khoản đầu tư xứng đáng cho chất lượng lâu dài của ứng dụng.
Giới thiệu JUnit – Công cụ Kiểm thử Đơn vị Tiêu chuẩn cho Android
JUnit là một framework kiểm thử đơn vị cho ngôn ngữ Java. Vì Android được xây dựng trên nền tảng Java (và Kotlin chạy trên JVM), JUnit đã trở thành framework kiểm thử đơn vị mặc định và phổ biến nhất trong phát triển Android.
Mặc dù có các phiên bản JUnit khác nhau (JUnit 4, JUnit 5), Android Studio mặc định thường cấu hình sẵn với JUnit 4 cho các project mới. JUnit 4 cung cấp một bộ các annotation (chú thích) và phương thức assertion mạnh mẽ để giúp bạn viết và chạy các test case một cách hiệu quả.
JUnit cho phép bạn viết test case cho các lớp và hàm thuần túy Java/Kotlin mà không cần môi trường Android. Loại test này được gọi là **Local Unit Tests**.
Thiết lập Môi trường cho Unit Test
Khi bạn tạo một project Android mới trong Android Studio, môi trường cho Unit Test thường đã được thiết lập sẵn. Hãy cùng xem qua cấu trúc thư mục và các dependency cần thiết.
Cấu trúc thư mục:
Trong cửa sổ Project view của Android Studio (chọn chế độ “Android”), bạn sẽ thấy cấu trúc thư mục sau:
app/
├── java/
│ └── com.your_app_name/
│ └── ... (Mã nguồn chính của ứng dụng)
├── generated/
├── res/
├── test/
│ └── com.your_app_name/
│ └── ... (Mã nguồn Unit Test)
└── androidTest/
└── com.your_app_name/
└── ... (Mã nguồn Instrumented Test, bao gồm UI Test với Espresso)
Mã nguồn Unit Test của bạn sẽ nằm trong thư mục `test/` (hoặc `test/
Dependency trong build.gradle:
Để sử dụng JUnit, bạn cần khai báo dependency trong file `app/build.gradle` (module level). Khi tạo project mới, Android Studio sẽ thêm các dependency cần thiết. Dưới đây là ví dụ các dependency liên quan đến test:
dependencies {
// ... other dependencies
// Dependencies cho Local Unit Tests
testImplementation 'junit:junit:4.13.2' // hoặc phiên bản mới hơn
testImplementation 'androidx.test.ext:junit:1.1.5' // Nếu dùng AndroidX Test API cho local tests
testImplementation 'org.mockito:mockito-core:5.8.0' // Ví dụ về mocking framework (sẽ nói sau)
testImplementation 'org.jetbrains.kotlinx:kotlinx-coroutines-test:1.7.3' // Nếu test Coroutines
// Dependencies cho Instrumented Tests (chạy trên thiết bị/emulator)
androidTestImplementation 'androidx.test.ext:junit:1.1.5'
androidTestImplementation 'androidx.test.espresso:espresso-core:3.5.1'
androidTestImplementation 'androidx.test.runner:1.5.2'
// ... other androidTest dependencies
}
Lưu ý tiền tố `testImplementation` dành cho Local Unit Tests, còn `androidTestImplementation` dành cho Instrumented Tests (như Espresso tests). Trong bài này, chúng ta chỉ quan tâm đến các dependency có tiền tố `testImplementation`. (Bạn có thể tham khảo lại bài Gradle là gì? Cách sử dụng trong Phát triển Android nếu cần ôn lại về dependency).
Giải phẫu một Lớp Test JUnit
Một lớp test đơn vị với JUnit thường có cấu trúc rất đơn giản:
package com.your_app_name.test
import org.junit.After
import org.junit.Before
import org.junit.Test // Quan trọng nhất!
import org.junit.Assert.* // Để sử dụng các phương thức assert
class MyClassUnitTest { // Tên lớp test thường kết thúc bằng "Test" hoặc "UnitTest"
// Có thể khai báo biến ở đây để dùng chung cho các test methods
private lateinit var calculator: Calculator
@Before // Phương thức này chạy TRƯỚC MỖI test method có @Test
fun setUp() {
// Khởi tạo các đối tượng cần thiết cho test
calculator = Calculator()
println("Setup done for a test.") // Chỉ là ví dụ
}
@After // Phương thức này chạy SAU MỖI test method có @Test
fun tearDown() {
// Dọn dẹp tài nguyên nếu cần
println("Tear down done for a test.") // Chỉ là ví dụ
}
@Test // Đánh dấu đây là một test method
fun addition_isCorrect() {
// Logic của test: 3 + 2 = 5
val result = calculator.add(3, 2)
assertEquals("Phép cộng không đúng", 5, result) // Assertion: Kiểm tra kết quả có bằng 5 không
}
@Test // Một test method khác
fun subtraction_isCorrect() {
// Logic của test: 5 - 2 = 3
val result = calculator.subtract(5, 2)
assertEquals(3, result)
}
@Test // Một test method khác
fun multiplication_isCorrect() {
// Logic của test: 4 * 5 = 20
val result = calculator.multiply(4, 5)
assertEquals(20, result)
}
// JUnit 4 cũng có @BeforeClass và @AfterClass, chạy một lần duy nhất
// trước và sau TẤT CẢ các test methods trong lớp.
// Phải là static method (trong Kotlin cần @JvmStatic companion object)
/*
companion object {
@BeforeClass @JvmStatic
fun globalSetup() {
println("Running tests for Calculator class...")
}
@AfterClass @JvmStatic
fun globalTearDown() {
println("Finished running tests for Calculator class.")
}
}
*/
}
// Lớp Calculator đơn giản cần test
class Calculator {
fun add(a: Int, b: Int): Int {
return a + b
}
fun subtract(a: Int, b: Int): Int {
return a - b
}
fun multiply(a: Int, b: Int): Int {
return a * b
}
}
Giải thích các Annotation chính:
@Test: Bắt buộc phải có trên mỗi phương thức mà bạn muốn JUnit chạy như một test case. Phương thức này sẽ chứa logic test và các câu lệnh assertion.@Before: (JUnit 4) hoặc@BeforeEach(JUnit 5). Phương thức được đánh dấu bởi annotation này sẽ được chạy trước mỗi test method (có@Test). Nó rất hữu ích để thiết lập môi trường hoặc khởi tạo các đối tượng cần thiết cho từng test case riêng biệt.@After: (JUnit 4) hoặc@AfterEach(JUnit 5). Phương thức được đánh dấu bởi annotation này sẽ được chạy sau mỗi test method. Thường dùng để dọn dẹp tài nguyên hoặc trạng thái sau khi một test case kết thúc.@BeforeClass: (JUnit 4) hoặc@BeforeAll(JUnit 5). Phương thức được đánh dấu bởi annotation này sẽ được chạy một lần duy nhất trước tất cả các test method trong lớp test đó. Thường dùng cho các thiết lập tốn kém tài nguyên hoặc chỉ cần làm một lần cho cả lớp test. Lưu ý phải là static method trong JUnit 4 (dùng@JvmStatic companion objecttrong Kotlin).@AfterClass: (JUnit 4) hoặc@AfterAll(JUnit 5). Phương thức được đánh dấu bởi annotation này sẽ được chạy một lần duy nhất sau tất cả các test method trong lớp test đó. Dùng để dọn dẹp sau khi toàn bộ test trong lớp kết thúc. Tương tự, phải là static method trong JUnit 4.
Sử dụng @Before và @After giúp đảm bảo mỗi test method chạy trong một môi trường “sạch”, độc lập với các test method khác. Điều này là một nguyên tắc quan trọng trong Unit Testing: các test case phải độc lập với nhau.
| Annotation (JUnit 4) | Mô tả | Thời điểm chạy |
|---|---|---|
@Test |
Đánh dấu một phương thức là một test case. | Khi bạn chạy các test. |
@Before |
Chạy trước mỗi phương thức @Test. |
Trước mỗi test case. |
@After |
Chạy sau mỗi phương thức @Test. |
Sau mỗi test case. |
@BeforeClass |
Chạy một lần duy nhất trước tất cả các phương thức @Test trong lớp. |
Trước khi chạy test đầu tiên trong lớp. |
@AfterClass |
Chạy một lần duy nhất sau tất cả các phương thức @Test trong lớp. |
Sau khi chạy test cuối cùng trong lớp. |
Assertion – Xác minh Hành vi Mong đợi
Trái tim của một test method là phần xác minh kết quả. Sau khi thực hiện hành động cần test (ví dụ: gọi một phương thức), bạn cần kiểm tra xem kết quả có đúng như bạn mong đợi hay không. JUnit cung cấp một tập hợp các phương thức assertion trong lớp org.junit.Assert (hoặc kotlin.test khi sử dụng thư viện test của Kotlin, nhưng Assert của JUnit là phổ biến nhất) để làm việc này.
Một số phương thức assertion thường dùng:
assertEquals(expected, actual): Kiểm tra xem hai giá trị có bằng nhau không. Có thể thêm tham số đầu tiên là thông báo lỗi nếu assertion thất bại.assertTrue(condition): Kiểm tra xem điều kiện là true.assertFalse(condition): Kiểm tra xem điều kiện là false.assertNull(object): Kiểm tra xem đối tượng là null.assertNotNull(object): Kiểm tra xem đối tượng không phải null.assertSame(expected, actual): Kiểm tra xem hai biến có tham chiếu đến cùng một đối tượng không.assertNotSame(expected, actual): Kiểm tra xem hai biến có tham chiếu đến các đối tượng khác nhau không.assertArrayEquals(expectedArray, actualArray): Kiểm tra xem nội dung của hai mảng có bằng nhau không.
Khi một assertion thất bại, test method đó sẽ dừng lại ngay lập tức và được đánh dấu là “Failed”. Nếu tất cả các assertion trong một test method đều pass, test method đó được đánh dấu là “Passed”.
Viết Test Case Đầu Tiên của Bạn
Hãy cùng viết một lớp đơn giản và test nó bằng JUnit.
Giả sử bạn có một lớp tiện ích để xử lý chuỗi như sau:
package com.your_app_name.utils
class StringHelper {
/**
* Đảo ngược chuỗi.
*/
fun reverseString(input: String): String {
return input.reversed()
}
/**
* Kiểm tra chuỗi có phải palindrome không.
* Palindrome là chuỗi đọc xuôi hay ngược đều giống nhau (ví dụ: "madam", "level").
*/
fun isPalindrome(input: String): Boolean {
val cleanedInput = input.toLowerCase().filter { it.isLetterOrDigit() }
return cleanedInput == cleanedInput.reversed()
}
}
Bây giờ, hãy tạo một lớp test cho nó trong thư mục `test/`:
package com.your_app_name.test
import com.your_app_name.utils.StringHelper // Import lớp cần test
import org.junit.Test
import org.junit.Assert.* // Import các phương thức assertion
class StringHelperUnitTest {
@Test
fun reverseString_basic() {
val helper = StringHelper()
val original = "hello"
val expected = "olleh"
val actual = helper.reverseString(original)
assertEquals("Đảo ngược chuỗi cơ bản không đúng", expected, actual)
}
@Test
fun reverseString_withSpaces() {
val helper = StringHelper()
val original = "hello world"
val expected = "dlrow olleh"
val actual = helper.reverseString(original)
assertEquals("Đảo ngược chuỗi có khoảng trắng không đúng", expected, actual)
}
@Test
fun reverseString_emptyString() {
val helper = StringHelper()
val original = ""
val expected = ""
val actual = helper.reverseString(original)
assertEquals("Đảo ngược chuỗi rỗng không đúng", expected, actual)
}
@Test
fun isPalindrome_trueCase() {
val helper = StringHelper()
val input = "Madam" // Có cả chữ hoa, chữ thường
assertTrue("Kiểm tra palindrome ('Madam') không đúng", helper.isPalindrome(input))
}
@Test
fun isPalindrome_falseCase() {
val helper = StringHelper()
val input = "hello"
assertFalse("Kiểm tra palindrome ('hello') không đúng", helper.isPalindrome(input))
}
@Test
fun isPalindrome_withSpacesAndPunctuation() {
val helper = StringHelper()
val input = "A man, a plan, a canal: Panama" // Chuỗi palindrome phức tạp
assertTrue("Kiểm tra palindrome ('A man, a plan, a canal: Panama') không đúng", helper.isPalindrome(input))
}
@Test
fun isPalindrome_emptyStringCase() {
val helper = StringHelper()
val input = ""
assertTrue("Kiểm tra palindrome chuỗi rỗng không đúng", helper.isPalindrome(input))
}
}
Để chạy các test này trong Android Studio:
- Mở lớp test (`StringHelperUnitTest`).
- Click vào biểu tượng mũi tên màu xanh lá cây bên cạnh tên lớp hoặc tên từng phương thức test.
- Chọn “Run ‘StringHelperUnitTest'”.
Android Studio sẽ chạy các test trên JVM của máy tính của bạn và hiển thị kết quả trong cửa sổ Run.
Local Unit Tests vs. Instrumented Tests
Điều quan trọng cần phân biệt là **Local Unit Tests** (chạy trên JVM) và **Instrumented Tests** (chạy trên thiết bị hoặc giả lập Android).
- Local Unit Tests: Như chúng ta vừa làm, test các lớp và hàm không phụ thuộc vào Android framework (hoặc các dependency có thể mock/thay thế dễ dàng). Chúng chạy rất nhanh vì không cần khởi động môi trường Android. Đây là loại test bạn nên viết nhiều nhất.
- Instrumented Tests: Test các thành phần có liên quan chặt chẽ đến Android framework như Activities, Fragments, Context, Services, v.v. Chúng cần chạy trong môi trường Android thật (thiết bị hoặc giả lập) để có Context và các API của hệ thống. Các test UI với Espresso là một ví dụ điển hình của Instrumented Test.
Bài viết này tập trung vào Local Unit Tests với JUnit, vì đây là nền tảng cho việc kiểm thử logic nghiệp vụ (business logic) của ứng dụng – phần thường chiếm phần lớn code và ít thay đổi hơn giao diện người dùng. Để test các lớp phụ thuộc Android framework, bạn thường cần sử dụng các kỹ thuật như Mocking (sẽ nói sâu hơn trong một bài khác, hoặc bạn có thể tìm hiểu về thư viện như Mockito/MockK).
Các Nguyên tắc và Thực hành Tốt khi Viết Unit Test
Để Unit Test thực sự mang lại giá trị, hãy tuân thủ một số nguyên tắc và thực hành tốt:
- FAST Principles:
- Fast: Test nên chạy nhanh. Hàng trăm test chỉ nên mất vài giây. Điều này khuyến khích bạn chạy test thường xuyên.
- Automatic: Test nên được tự động hóa hoàn toàn. Không có sự can thiệp thủ công nào sau khi chạy test.
- Self-validating: Test nên tự báo cáo kết quả (Passed/Failed) mà không cần con người kiểm tra output. Assertion giúp điều này.
- Timely: Viết test càng sớm càng tốt, lý tưởng là viết test trước khi viết code triển khai chức năng (Test-Driven Development – TDD).
- Test Một Thứ Duy Nhất: Mỗi test method (được đánh dấu
@Test) chỉ nên test một chức năng cụ thể hoặc một kịch bản duy nhất của đơn vị đang test. Điều này giúp bạn dễ dàng xác định lỗi khi một test thất bại. - Độc lập: Các test case không nên phụ thuộc vào kết quả hoặc trạng thái của các test case khác. Sử dụng
@Beforevà@Afterđể đảm bảo môi trường “sạch” cho mỗi test. - Dễ đọc và Dễ hiểu: Tên test method nên rõ ràng, mô tả chức năng hoặc hành vi đang được test (ví dụ:
addition_isCorrect,isPalindrome_withSpacesAndPunctuation). Cấu trúc test (Arrange-Act-Assert) cũng giúp tăng tính đọc hiểu. - Test các kịch bản biên (Edge Cases): Đừng chỉ test các trường hợp bình thường. Hãy test các input là null, rỗng, giá trị âm, giá trị rất lớn, giới hạn của danh sách, v.v.
- Sử dụng Mocking cho Dependencies: Khi lớp bạn test phụ thuộc vào các lớp khác (đặc biệt là các lớp khó test như API mạng, cơ sở dữ liệu, hoặc các lớp Android framework), hãy sử dụng mocking framework (như Mockito, MockK) để tạo đối tượng giả thay thế các dependency này. Điều này giúp cô lập đơn vị đang test và giữ cho Unit Test nhanh chóng, độc lập. (Kiểm thử với các dependency thật sẽ thuộc về Kiểm thử Tích hợp).
Việc tuân thủ những nguyên tắc này sẽ giúp bộ test của bạn hiệu quả, đáng tin cậy và dễ bảo trì.
Kết luận
Kiểm thử đơn vị với JUnit là một kỹ năng không thể thiếu đối với bất kỳ Lập trình viên Android chuyên nghiệp nào. Nó không chỉ giúp bạn tìm và sửa lỗi sớm hơn mà còn thúc đẩy bạn viết mã nguồn sạch, dễ bảo trì và tăng sự tự tin khi thay đổi code.
Trong bài viết này, chúng ta đã tìm hiểu Unit Testing là gì, tại sao nó quan trọng, cách thiết lập JUnit trong project Android, cấu trúc một lớp test, các annotation và phương thức assertion cơ bản, và các thực hành tốt. Chúng ta cũng đã phân biệt Local Unit Tests với Instrumented Tests.
Hãy bắt đầu áp dụng ngay những kiến thức này vào các project của bạn. Hãy viết test cho các lớp ViewModel, các lớp xử lý logic nghiệp vụ, các lớp tiện ích,… Những nỗ lực ban đầu này sẽ được đền đáp xứng đáng về sau.
Unit Testing chỉ là bước khởi đầu trong thế giới kiểm thử Android. Ở các bài tiếp theo, chúng ta có thể sẽ đi sâu hơn vào các chủ đề nâng cao hơn như Mocking, Kiểm thử Tích hợp, và cách áp dụng kiểm thử vào các kiến trúc ứng dụng hiện đại (ví dụ: test các thành phần trong kiến trúc MVVM). Đừng bỏ lỡ nhé!
Hẹn gặp lại các bạn ở bài viết tiếp theo trên Android Developer Roadmap!
