Giới thiệu Unit Test, Widget Test và Integration Test trong Flutter
Tóm tắt nhanh
Tìm hiểu về 3 loại testing trong Flutter: Unit Test, Widget Test và Integration Test - khi nào dùng loại nào.
Mục lục bài viết (29)
- Testing Pyramid
- 1. Unit Test
- Định nghĩa:
- Khi nào dùng:
- Ví dụ:
- Chạy Unit Test:
- 2. Widget Test
- Định nghĩa:
- Khi nào dùng:
- Ví dụ:
- Chạy Widget Test:
- 3. Integration Test
- Định nghĩa:
- Khi nào dùng:
- Ví dụ:
- Setup Integration Test:
- Chạy Integration Test:
- So sánh 3 loại Test
- Best Practices
- 1. Test Coverage
- 2. Test Naming
- 3. Test Organization
- 4. Mocking
- Nên viết bao nhiêu test và viết ở tầng nào
- Những thứ không nên test
- Quy ước khi viết test
- Kết luận
- Tóm tắt:
- Học Flutter bài bản theo lộ trình
Testing là phần quan trọng trong phát triển ứng dụng. Flutter hỗ trợ 3 loại testing: Unit Test, Widget Test và Integration Test. Bài viết này sẽ giúp bạn hiểu rõ từng loại.
Testing Pyramid
[object Object]1. Unit Test
Định nghĩa:
Unit Test kiểm tra một function, method hoặc class riêng lẻ trong isolation.
Khi nào dùng:
- ✅ Test business logic
- ✅ Test utility functions
- ✅ Test data transformations
- ✅ Test calculations
Ví dụ:
[object Object][object Object]Chạy Unit Test:
[object Object]2. Widget Test
Định nghĩa:
Widget Test kiểm tra một widget riêng lẻ trong isolation với test environment.
Khi nào dùng:
- ✅ Test UI components
- ✅ Test user interactions
- ✅ Test widget rendering
- ✅ Test state changes
Ví dụ:
[object Object][object Object]Chạy Widget Test:
[object Object]3. Integration Test
Định nghĩa:
Integration Test kiểm tra toàn bộ ứng dụng hoặc một flow hoàn chỉnh trên device/emulator thật.
Khi nào dùng:
- ✅ Test user flows
- ✅ Test end-to-end scenarios
- ✅ Test performance
- ✅ Test trên real devices
Ví dụ:
[object Object]Setup Integration Test:
[object Object]Chạy Integration Test:
[object Object]So sánh 3 loại Test
| Tiêu chí | Unit Test | Widget Test | Integration Test |
|---|---|---|---|
| Tốc độ | Rất nhanh | Nhanh | Chậm |
| Scope | Function/Method | Widget | Toàn bộ app |
| Environment | Isolated | Test environment | Real device |
| Cost | Thấp | Trung bình | Cao |
| Coverage | Business logic | UI components | User flows |
Best Practices
1. Test Coverage
✅ Nên: Aim for 80%+ coverage
❌ Không nên: 100% coverage (không cần thiết)
2. Test Naming
[object Object]3. Test Organization
[object Object]4. Mocking
[object Object]Nên viết bao nhiêu test và viết ở tầng nào
Câu hỏi này không có câu trả lời theo con số tuyệt đối, nhưng có cách suy nghĩ rõ ràng. Hãy chọn tầng test theo loại rủi ro:
- SQL/ui sai, công thức sai, dữ liệu bị biến đổi sai — viết ở tầng đơn vị. Đây là tầng chạy nhanh nhất và cho phản hồi rõ nhất.
- Màn hình hiển thị sai trạng thái, nút không hoạt động, luồng nhập liệu sai — viết ở tầng widget. Số lượng nên vừa phải, tập trung vào các luồng quan trọng.
- Luồng từ đầu đến cuối — chỉ viết cho những đường đi chính như đăng nhập, thanh toán, đăng ký. Loại test này chậm và dễ hỏng, nên số lượng nên rất ít.
Một tỉ lệ hợp lý cho ứng dụng thực tế là rất nhiều test đơn vị, một số test widget cho những luồng quan trọng, và số ít test đầu–cuối. Nếu bạn đang viết nhiều test đầu–cuối hơn test đơn vị, bộ test sẽ chậm và bạn sẽ sớm bỏ qua nó.
Những thứ không nên test
Kiểm thử cũng có chi phí, và có những thứ không xứng với chi phí đó:
- Mã của framework. Không cần kiểm tra rằng
Columnxếp con theo chiều dọc; đó là việc của Flutter. - Chi tiết trình bày thuần tuý như màu sắc hay khoảng cách, trừ khi dùng test ảnh mẫu một cách có chủ đích. Những thay đổi thiết kế sẽ làm test đỏ liên tục mà không phản ánh lỗi thật.
- Mã tự sinh từ công cụ.
- Những hàm chỉ gọi thẳng một hàm khác mà không thêm logic.
Nguyên tắc chung: nếu test chỉ lặp lại nội dung của code, nó không mang thêm thông tin nào về việc code có đúng hay không.
Quy ước khi viết test
Những quy ước nhỏ dưới đây giúp bộ test dùng được lâu dài, đặc biệt khi dự án có nhiều người:
- Tên test mô tả hành vi, ví dụ "hiện thông báo lỗi khi email sai" thay vì "testEmail2". Tên là tài liệu đầu tiên của bộ test.
- Mỗi test kiểm tra một việc. Một test khẳng định năm thứ sẽ rất khó chỉ ra nguyên nhân khi đỏ.
- Không phụ thuộc thứ tự chạy. Trạng thái dùng chung giữa các test là nguồn gốc của những lần "chạy một mình thì xanh, chạy cả bộ thì đỏ".
- Tránh giới hạn thời gian trong test, vì nó tạo ra lỗi không ổn định trên máy yếu.
- Chạy test tự động trong quy trình đóng góp mã, vì test không được chạy thường xuyên thì sẽ xuống cấp nhanh.
Và một lời khuyên về con số bao phủ: đừng đặt mục tiêu "bao phủ bao nhiêu phần trăm" cho cả dự án. Hãy đặt mục tiêu theo phần quan trọng — tầng xử lý dữ liệu và luồng thanh toán, đăng nhập nên được bao phủ cao nhất.
Kết luận
3 loại testing trong Flutter:
- ✅ Unit Test: Test business logic, nhanh, nhiều nhất
- ✅ Widget Test: Test UI components, trung bình
- ✅ Integration Test: Test user flows, chậm, ít nhất
Tóm tắt:
- Unit Test: Test functions, methods, classes
- Widget Test: Test widgets và interactions
- Integration Test: Test toàn bộ app flows
- Balance: Kết hợp cả 3 loại để có coverage tốt
Sử dụng đúng loại test sẽ giúp ứng dụng Flutter của bạn chất lượng và ổn định hơn! 🚀
Học Flutter bài bản theo lộ trình
Nếu bạn muốn học có người sửa bài thay vì tự ghép tài liệu, Flutter Hướng Nghiệp đào tạo theo 3 cấp:
- Flutter Cơ Bản — Dart, widget, giao diện, 28 buổi.
- Flutter Nâng Cao — state management, REST API, Firebase, 28 buổi.
- Flutter Chuyên Sâu — back-end, AI/ML, publish lên store, 53 buổi.
Lớp online trực tiếp qua Zoom/Google Meet, có bản ghi lại — không bắt buộc đến cơ sở.
Xem lịch khai giảng hoặc so sánh 5 cách học lập trình mobile nếu còn phân vân.