Widget Testing và Integration Testing là hai phương pháp kiểm thử quan trọng trong Flutter, giúp lập trình viên xác minh giao diện, hành vi của từng thành phần và khả năng hoạt động của toàn bộ ứng dụng. Khi phát triển ứng dụng thực tế, việc kiểm tra bằng cách chạy ứng dụng rồi thao tác thủ công thường không đủ để phát hiện tất cả lỗi, đặc biệt khi dự án có nhiều màn hình, nhiều trạng thái giao diện, API và các luồng nghiệp vụ phức tạp.

Widget Testing tập trung vào việc kiểm tra từng Widget hoặc một nhóm Widget trong môi trường kiểm thử của Flutter. Integration Testing tập trung vào việc kiểm tra sự phối hợp giữa nhiều thành phần trong ứng dụng thông qua những luồng thao tác gần với cách người dùng sử dụng ứng dụng thực tế.

Hai phương pháp này bổ sung cho nhau trong quy trình đảm bảo chất lượng phần mềm. Widget Testing giúp phát hiện lỗi ở phạm vi nhỏ với tốc độ nhanh, trong khi Integration Testing giúp xác minh rằng các thành phần khi kết hợp với nhau vẫn hoạt động đúng như mong đợi.

1. Tổng quan về kiểm thử trong Flutter

Kiểm thử phần mềm (Software Testing) là quá trình đánh giá một chương trình nhằm xác định xem chương trình có hoạt động đúng theo yêu cầu hay không. Trong Flutter, kiểm thử giúp xác minh logic xử lý, giao diện người dùng, tương tác giữa các thành phần và các luồng nghiệp vụ quan trọng.

Flutter cung cấp những công cụ kiểm thử tích hợp sẵn trong hệ sinh thái Dart, cho phép lập trình viên xây dựng các bài kiểm thử tự động mà không cần phải dựa hoàn toàn vào thao tác thủ công.

Các bài kiểm thử thường được tổ chức thành nhiều cấp độ:

• Unit Testing: Kiểm tra một đơn vị logic độc lập, chẳng hạn như hàm tính tổng tiền, phương thức kiểm tra dữ liệu hoặc một lớp xử lý nghiệp vụ.

• Widget Testing: Kiểm tra giao diện và hành vi của Widget trong môi trường kiểm thử Flutter.

• Integration Testing: Kiểm tra sự phối hợp giữa các thành phần trong ứng dụng thông qua những luồng thao tác hoàn chỉnh.

• Manual Testing: Kiểm thử thủ công bằng cách chạy ứng dụng và trực tiếp thao tác trên giao diện.

Trong một dự án Flutter, các cấp độ kiểm thử không thay thế hoàn toàn cho nhau. Một hàm xử lý đăng nhập có thể được kiểm tra bằng Unit Testing, giao diện đăng nhập có thể được kiểm tra bằng Widget Testing, còn toàn bộ quy trình từ nhập tài khoản, gửi yêu cầu đến máy chủ và chuyển sang màn hình chính có thể được kiểm tra bằng Integration Testing.

Việc kết hợp các cấp độ kiểm thử giúp phát hiện lỗi ở nhiều phạm vi khác nhau và hạn chế tình trạng một chức năng chỉ hoạt động đúng khi được kiểm tra riêng lẻ.

2. Widget Testing

2.1. Khái niệm Widget Testing

Widget Testing là phương pháp kiểm thử tự động dùng để xác minh cách một Widget được xây dựng, hiển thị và phản hồi khi có tương tác hoặc thay đổi trạng thái.

Trong Flutter, hầu hết các thành phần giao diện đều được biểu diễn dưới dạng Widget, bao gồm:

• Text: Hiển thị văn bản.

• ElevatedButton: Hiển thị nút bấm.

• TextField: Cho phép người dùng nhập dữ liệu.

• Checkbox: Cho phép chọn hoặc bỏ chọn.

• ListView: Hiển thị danh sách.

• Form: Quản lý biểu mẫu và xác thực dữ liệu.

• Scaffold: Cung cấp cấu trúc cơ bản cho một màn hình.

• Các Widget tùy chỉnh do lập trình viên xây dựng.

Widget Testing cho phép kiểm tra các thành phần này trong một môi trường kiểm thử có thể điều khiển được. Lập trình viên có thể tạo Widget, mô phỏng thao tác của người dùng, cập nhật trạng thái và xác minh kết quả nhận được.

Ví dụ, với một nút có nội dung Đăng nhập, bài kiểm thử có thể xác minh rằng:

• Nút được hiển thị trên màn hình.

• Văn bản trên nút chính xác.

• Nút có thể nhận thao tác nhấn.

• Callback được gọi khi người dùng nhấn nút.

• Nút bị vô hiệu hóa khi dữ liệu không hợp lệ.

• Giao diện thay đổi khi trạng thái xử lý được cập nhật.

Điểm quan trọng là Widget Testing không chỉ kiểm tra xem giao diện có xuất hiện hay không, mà còn xác minh hành vi của giao diện theo các điều kiện cụ thể.

2.2. Mục tiêu của Widget Testing

Widget Testing thường được sử dụng để kiểm tra tính đúng đắn của các thành phần giao diện và hành vi liên quan trực tiếp đến chúng.

Kiểm tra cấu trúc giao diện: Xác minh các Widget cần thiết đã được tạo và xuất hiện trong cây Widget.

Kiểm tra nội dung: Xác minh văn bản, nhãn, tiêu đề, thông báo lỗi và dữ liệu được hiển thị chính xác.

Kiểm tra tương tác: Mô phỏng thao tác nhấn nút, nhập văn bản, chọn checkbox, cuộn danh sách hoặc chuyển đổi trạng thái.

Kiểm tra trạng thái: Xác minh giao diện phản ánh đúng các trạng thái như tải dữ liệu, thành công, thất bại, không có dữ liệu hoặc dữ liệu không hợp lệ.

Kiểm tra điều kiện hiển thị: Xác minh Widget xuất hiện hoặc biến mất dựa trên điều kiện nghiệp vụ.

Kiểm tra khả năng tái sử dụng: Xác minh một Widget dùng chung hoạt động đúng với nhiều bộ dữ liệu đầu vào khác nhau.

Ví dụ, một Widget hiển thị thông tin sản phẩm có thể được kiểm tra với sản phẩm còn hàng, hết hàng, có giá khuyến mãi hoặc thiếu hình ảnh. Mỗi trường hợp giúp xác minh rằng giao diện xử lý đúng dữ liệu thay vì chỉ hoạt động với một tình huống duy nhất.

2.3. Cơ chế hoạt động của Widget Testing

Widget Testing thường sử dụng hàm testWidgets() được cung cấp bởi thư viện flutter_test.

Một bài kiểm thử cơ bản có các thành phần:

1. Khởi tạo môi trường kiểm thử.

2. Tạo Widget cần kiểm tra.

3. Đưa Widget vào cây giao diện thông qua pumpWidget().

4. Tìm Widget bằng các công cụ tìm kiếm như find.text() hoặc find.byType().

5. Thực hiện thao tác bằng tester.tap(), tester.enterText() hoặc các phương thức tương ứng.

6. Cập nhật giao diện bằng pump() hoặc pumpAndSettle() khi cần thiết.

7. Xác minh kết quả bằng expect() và các matcher.

Quy trình này giúp bài kiểm thử có thể tái hiện nhiều lần với cùng điều kiện đầu vào, từ đó hỗ trợ phát hiện lỗi một cách ổn định.

2.4. Các công cụ quan trọng trong Widget Testing

Flutter cung cấp nhiều API để xây dựng và điều khiển bài kiểm thử giao diện.

Các công cụ này phối hợp với nhau để xây dựng những bài kiểm thử có tính xác định và dễ bảo trì.

Một điểm cần chú ý là pump() và pumpAndSettle() không hoàn toàn giống nhau. pump() thường được sử dụng khi muốn kiểm soát việc cập nhật frame, còn pumpAndSettle() hữu ích khi cần chờ một chuỗi animation hoặc quá trình cập nhật giao diện kết thúc. Nếu ứng dụng có animation lặp vô hạn, chẳng hạn hiệu ứng loading liên tục, pumpAndSettle() có thể không hoàn tất và gây timeout.

2.5. Xây dựng Widget Testing đầu tiên

Giả sử ứng dụng có một Widget hiển thị nút bấm đơn giản.

Tạo file lib/widgets/counter_button.dart:

import 'package:flutter/material.dart';

class CounterButton extends StatefulWidget {
  const CounterButton({super.key});

  @override
  State<CounterButton> createState() => _CounterButtonState();
}

class _CounterButtonState extends State<CounterButton> {
  int count = 0;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Column(
          mainAxisSize: MainAxisSize.min,
          children: [
            Text('Count: $count'),
            ElevatedButton(
              onPressed: () {
                setState(() {
                  count++;
                });
              },
              child: const Text('Increment'),
            ),
          ],
        ),
      ),
    );
  }
}

Widget này hiển thị giá trị đếm và một nút cho phép tăng giá trị lên một đơn vị mỗi khi được nhấn.

Tạo file test/widgets/counter_button_test.dart:

import 'package:flutter_test/flutter_test.dart';
import 'package:flutter/material.dart';
import 'package:your_app/widgets/counter_button.dart';

void main() {
  testWidgets(
    'Counter increases when button is tapped',
    (WidgetTester tester) async {
      await tester.pumpWidget(
        const MaterialApp(
          home: CounterButton(),
        ),
      );

      expect(find.text('Count: 0'), findsOneWidget);

      await tester.tap(find.text('Increment'));
      await tester.pump();

      expect(find.text('Count: 1'), findsOneWidget);
    },
  );
}

Thay your_app bằng tên package được khai báo trong file pubspec.yaml của dự án.

Trong ví dụ này, bài kiểm thử thực hiện ba bước chính. Đầu tiên, Widget được tạo trong một MaterialApp. Tiếp theo, bài kiểm thử xác minh giá trị ban đầu bằng find.text('Count: 0'). Cuối cùng, chương trình mô phỏng thao tác nhấn nút, cập nhật giao diện và xác minh giá trị đã tăng lên thành Count: 1.

Bài kiểm thử không cần mở ứng dụng bằng tay, không cần người dùng trực tiếp nhấn nút trên thiết bị và có thể chạy lại nhiều lần.

2.6. Kiểm thử nội dung và cấu trúc giao diện

Một ứng dụng thường chứa nhiều Widget lồng nhau. Vì vậy, việc xác minh cấu trúc giao diện là một phần quan trọng của Widget Testing.

Ví dụ, màn hình đăng nhập cần có tiêu đề, hai trường nhập liệu và một nút gửi dữ liệu.

testWidgets('Login screen displays required widgets',
    (WidgetTester tester) async {
  await tester.pumpWidget(
    const MaterialApp(
      home: Scaffold(
        body: Column(
          children: [
            Text('Login'),
            TextField(
              decoration: InputDecoration(
                hintText: 'Email',
              ),
            ),
            TextField(
              decoration: InputDecoration(
                hintText: 'Password',
              ),
            ),
            ElevatedButton(
              onPressed: null,
              child: Text('Submit'),
            ),
          ],
        ),
      ),
    ),
  );

  expect(find.text('Login'), findsOneWidget);
  expect(find.byType(TextField), findsNWidgets(2));
  expect(find.text('Submit'), findsOneWidget);
});

Bài kiểm thử này xác minh rằng màn hình có tiêu đề Login, hai trường nhập liệu và nút Submit.

Cách kiểm tra này phù hợp với những thành phần giao diện quan trọng, đặc biệt khi dự án có nhiều màn hình dùng chung các Widget tùy chỉnh.

Tuy nhiên, chỉ kiểm tra sự tồn tại của Widget chưa đủ để khẳng định toàn bộ giao diện hoạt động chính xác. Một nút có thể xuất hiện nhưng callback không được thực thi, hoặc một trường nhập liệu có thể hiển thị nhưng không lưu được dữ liệu. Vì vậy, cần kết hợp kiểm tra cấu trúc với kiểm tra hành vi.

2.7. Kiểm thử tương tác người dùng

Widget Testing cho phép mô phỏng các thao tác thường gặp trong ứng dụng.

Ví dụ, kiểm tra khả năng nhập email:

testWidgets('Email field accepts user input',
    (WidgetTester tester) async {
  await tester.pumpWidget(
    const MaterialApp(
      home: Scaffold(
        body: TextField(
          key: Key('email_field'),
        ),
      ),
    ),
  );

  await tester.enterText(
    find.byKey(const Key('email_field')),
    '[email protected]',
  );

  expect(
    find.text('[email protected]'),
    findsOneWidget,
  );
});

Ở đây, Key được dùng để định danh trường nhập liệu. Cách này hữu ích khi giao diện có nhiều trường cùng loại hoặc khi nội dung hiển thị có thể thay đổi.

Ngoài thao tác nhập liệu, lập trình viên có thể mô phỏng:

• Nhấn nút gửi biểu mẫu.

• Chọn một mục trong danh sách.

• Chuyển đổi checkbox.

• Mở hoặc đóng dialog.

• Cuộn danh sách.

• Chuyển tab.

• Mở menu.

• Thực hiện thao tác kéo thả nếu Widget hỗ trợ.

Mỗi thao tác cần đi kèm một điều kiện xác minh phù hợp. Chẳng hạn, sau khi nhấn nút mở dialog, bài kiểm thử cần xác minh dialog xuất hiện; sau khi nhấn nút đóng, bài kiểm thử cần xác minh dialog không còn tồn tại.

2.8. Kiểm thử trạng thái giao diện

Giao diện Flutter thường thay đổi theo dữ liệu và trạng thái xử lý. Một màn hình có thể có các trạng thái loading, success, error và empty.

Ví dụ, khi tải danh sách sản phẩm từ API, ứng dụng có thể hiển thị vòng tròn loading, danh sách sản phẩm hoặc thông báo lỗi.

Widget Testing có thể kiểm tra riêng từng trạng thái bằng cách cung cấp dữ liệu đầu vào hoặc trạng thái giả lập phù hợp.

Một số trường hợp thường cần kiểm thử:

• Dữ liệu chưa được tải và giao diện hiển thị loading.

• Dữ liệu được tải thành công và danh sách xuất hiện.

• Máy chủ trả về lỗi và thông báo lỗi được hiển thị.

• Danh sách không có dữ liệu và giao diện hiển thị trạng thái empty.

• Người dùng thử tải lại dữ liệu sau khi xảy ra lỗi.

• Nút gửi bị vô hiệu hóa trong quá trình xử lý.

• Thông báo lỗi biến mất sau khi dữ liệu được sửa hợp lệ.

Để kiểm thử tốt những tình huống này, nên thiết kế Widget có thể nhận dữ liệu hoặc trạng thái từ bên ngoài. Việc tách phần giao diện khỏi phần truy cập dữ liệu giúp dễ dàng cung cấp các trạng thái giả lập trong bài kiểm thử.

2.9. Kiểm thử Form và xác thực dữ liệu

Form là thành phần phổ biến trong ứng dụng Flutter, đặc biệt ở các chức năng đăng nhập, đăng ký, cập nhật hồ sơ và đặt hàng.

Các quy tắc xác thực thường bao gồm:

• Trường bắt buộc không được để trống.

• Email phải đúng định dạng.

• Mật khẩu phải đáp ứng độ dài tối thiểu.

• Hai trường xác nhận mật khẩu phải khớp nhau.

• Số điện thoại phải đáp ứng quy tắc định dạng được yêu cầu.

• Thông báo lỗi phải xuất hiện khi dữ liệu không hợp lệ.

• Dữ liệu hợp lệ phải cho phép tiếp tục quy trình.

Ví dụ:

testWidgets('Form shows error for empty email',
    (WidgetTester tester) async {
  final formKey = GlobalKey<FormState>();

  await tester.pumpWidget(
    MaterialApp(
      home: Scaffold(
        body: Form(
          key: formKey,
          child: TextFormField(
            decoration: const InputDecoration(
              labelText: 'Email',
            ),
            validator: (value) {
              if (value == null || value.isEmpty) {
                return 'Email is required';
              }
              return null;
            },
          ),
        ),
      ),
    ),
  );

  formKey.currentState!.validate();
  await tester.pump();

  expect(
    find.text('Email is required'),
    findsOneWidget,
  );
});

Ví dụ này kiểm tra quy tắc xác thực của trường email. Khi giá trị đầu vào rỗng, validator trả về thông báo lỗi và giao diện hiển thị thông báo đó.

Trong dự án thực tế, nên kiểm thử cả trường hợp hợp lệ, không hợp lệ và các giá trị biên để tránh tình trạng biểu mẫu chỉ hoạt động đúng với một số dữ liệu nhất định.

2.10. Kiểm thử Widget có phụ thuộc vào Theme và môi trường

Một số Widget phụ thuộc vào Theme, MediaQuery, Localizations, Navigator hoặc các thành phần được cung cấp từ cây Widget phía trên.

Nếu đưa trực tiếp Widget vào môi trường kiểm thử mà thiếu những thành phần này, bài kiểm thử có thể gặp lỗi dù Widget vẫn hoạt động bình thường khi chạy trong ứng dụng đầy đủ.

Ví dụ, Widget sử dụng Theme.of(context) cần được đặt trong một môi trường có Theme phù hợp. Tương tự, Widget cần điều hướng có thể cần MaterialApp hoặc Navigator.

Khi viết Widget Testing, cần tạo môi trường kiểm thử tương ứng với các dependency mà Widget sử dụng. Không nhất thiết phải khởi tạo toàn bộ ứng dụng, nhưng cần cung cấp đầy đủ những thành phần mà Widget thực sự phụ thuộc vào.

2.11. Giới hạn của Widget Testing

Widget Testing rất hữu ích nhưng không thể thay thế hoàn toàn Integration Testing.

Một bài kiểm thử Widget có thể xác minh rằng nhấn nút sẽ gọi callback. Tuy nhiên, điều đó không chứng minh rằng yêu cầu HTTP thực sự được gửi chính xác đến máy chủ, cơ sở dữ liệu lưu đúng dữ liệu hoặc toàn bộ quy trình đăng nhập hoạt động trên thiết bị thật.

Các giới hạn thường gặp gồm:

• Không tự động chứng minh mọi chức năng bên ngoài Widget hoạt động chính xác.

• Không đảm bảo API thực tế tương thích với giao diện.

• Không thay thế việc kiểm tra hành vi trên thiết bị và hệ điều hành thật.

• Không tự động phát hiện mọi vấn đề về hiệu năng, bộ nhớ hoặc trải nghiệm sử dụng.

• Có thể phát sinh bài kiểm thử khó bảo trì nếu phụ thuộc quá nhiều vào cấu trúc nội bộ của giao diện.

Do đó, Widget Testing nên tập trung vào hành vi và kết quả quan sát được, thay vì kiểm tra quá chi tiết những thành phần nội bộ không có ý nghĩa đối với người sử dụng.

3. Integration Testing

3.1. Khái niệm Integration Testing

Integration Testing là phương pháp kiểm thử nhằm xác minh rằng nhiều thành phần của phần mềm có thể phối hợp với nhau đúng cách.

Trong Flutter, Integration Testing thường được sử dụng để kiểm tra những luồng thao tác có sự tham gia của nhiều thành phần, chẳng hạn giao diện, quản lý trạng thái, tầng gọi API, lưu trữ cục bộ và điều hướng màn hình.

Ví dụ, trong chức năng đăng nhập, người dùng thực hiện các thao tác sau:

1. Mở màn hình đăng nhập.

2. Nhập email và mật khẩu.

3. Nhấn nút đăng nhập.

4. Ứng dụng gửi yêu cầu đến máy chủ.

5. Máy chủ trả về kết quả xác thực.

6. Ứng dụng lưu thông tin phiên đăng nhập theo thiết kế.

7. Giao diện chuyển sang màn hình chính.

Integration Testing có thể kiểm tra toàn bộ chuỗi này để xác minh rằng các thành phần không chỉ hoạt động riêng lẻ mà còn kết nối đúng với nhau.

Khác với Widget Testing, Integration Testing thường chạy trên thiết bị hoặc trình giả lập, sử dụng môi trường chạy ứng dụng thực tế hơn và có thể bao gồm nhiều màn hình trong cùng một bài kiểm thử.

3.2. Mục tiêu của Integration Testing

Integration Testing hướng đến việc phát hiện lỗi xảy ra tại ranh giới giữa các thành phần.

Kiểm tra giao tiếp giữa các tầng: Xác minh giao diện gửi dữ liệu chính xác đến tầng xử lý nghiệp vụ và nhận kết quả phù hợp.

Kiểm tra điều hướng: Xác minh ứng dụng chuyển đến đúng màn hình sau khi hoàn tất một hành động.

Kiểm tra tích hợp API: Xác minh ứng dụng xử lý đúng phản hồi từ máy chủ, bao gồm dữ liệu thành công và lỗi.

Kiểm tra lưu trữ: Xác minh dữ liệu được lưu và đọc lại chính xác khi các thành phần cùng hoạt động.

Kiểm tra luồng nghiệp vụ: Xác minh người dùng có thể hoàn thành một quy trình từ đầu đến cuối.

Kiểm tra trạng thái giữa các màn hình: Xác minh dữ liệu và trạng thái được duy trì đúng khi người dùng điều hướng qua nhiều màn hình.

Ví dụ, một chức năng thêm sản phẩm vào giỏ hàng có thể hoạt động đúng trong từng Widget riêng lẻ nhưng vẫn gặp lỗi khi tích hợp. Số lượng sản phẩm có thể không cập nhật trên biểu tượng giỏ hàng, dữ liệu có thể không được lưu, hoặc tổng tiền có thể không thay đổi sau khi người dùng sửa số lượng.

Integration Testing giúp kiểm tra những vấn đề liên quan đến sự phối hợp giữa các thành phần này.

3.3. Công cụ Integration Testing trong Flutter

Flutter cung cấp package integration_test để xây dựng các bài kiểm thử tích hợp.

Package này hỗ trợ chạy ứng dụng trong môi trường thực thi và tương tác với giao diện bằng những thao tác tương tự cách người dùng sử dụng ứng dụng.

Các thành phần thường gặp gồm:

Một điểm cần phân biệt là Integration Testing của Flutter vẫn có thể sử dụng testWidgets(), WidgetTester, Finder và các matcher quen thuộc. Khác biệt chính nằm ở môi trường chạy, phạm vi tích hợp và cách bài kiểm thử được thực thi, chứ không đơn thuần nằm ở tên hàm kiểm thử.

3.4. Cơ chế hoạt động của Integration Testing

Quy trình Integration Testing thường bao gồm những bước sau:

Trước khi chạy bài kiểm thử, ứng dụng cần được khởi tạo đúng cấu hình. Sau đó, bài kiểm thử tương tác với ứng dụng, chờ các thao tác bất đồng bộ cần thiết hoàn tất và kiểm tra kết quả.

Tùy theo phạm vi, bài kiểm thử có thể sử dụng API thật trong môi trường thử nghiệm hoặc thay thế một số dịch vụ bằng dữ liệu giả lập. Nếu mục tiêu là kiểm tra khả năng tích hợp với máy chủ, cần sử dụng môi trường backend phù hợp và dữ liệu có thể kiểm soát được.

3.5. Cài đặt môi trường Integration Testing

Với dự án Flutter thông thường, có thể thêm package bằng lệnh:

flutter pub add --dev integration_test

Sau đó, tạo cấu trúc thư mục:

my_flutter_app/
├── lib/
│   ├── main.dart
│   └── screens/
├── test/
│   └── widget_test.dart
├── integration_test/
│   └── app_test.dart
└── pubspec.yaml

Thư mục test/ thường chứa Unit Testing và Widget Testing. Thư mục integration_test/ chứa những bài kiểm thử tích hợp.

Đây là cách tổ chức phổ biến, không phải quy định bắt buộc duy nhất. Một dự án lớn có thể chia thư mục kiểm thử thành nhiều nhóm theo tính năng, chẳng hạn đăng nhập, giỏ hàng, thanh toán hoặc quản lý tài khoản.

Để chạy Integration Testing trên Android Emulator hoặc thiết bị Android đã kết nối, cần đảm bảo Flutter nhận diện được thiết bị:

flutter devices

Sau đó, chạy bài kiểm thử:

flutter test integration_test/app_test.dart

Lệnh trên sử dụng cơ chế chạy kiểm thử tích hợp do Flutter hỗ trợ. Nếu cấu hình dự án hoặc nền tảng yêu cầu cách khởi chạy riêng, cần làm theo hướng dẫn tương ứng của Flutter cho Android hoặc iOS.

3.6. Xây dựng Integration Testing đầu tiên

Giả sử ứng dụng có màn hình chính hiển thị nút tăng số lượng. Khi người dùng nhấn nút, giá trị trên màn hình thay đổi.

Tạo file integration_test/app_test.dart:

import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:integration_test/integration_test.dart';
import 'package:your_app/main.dart' as app;

void main() {
  IntegrationTestWidgetsFlutterBinding.ensureInitialized();

  testWidgets(
    'Counter increases after tapping the button',
    (WidgetTester tester) async {
      app.main();
      await tester.pumpAndSettle();

      expect(find.text('0'), findsOneWidget);

      await tester.tap(find.byIcon(Icons.add));
      await tester.pumpAndSettle();

      expect(find.text('1'), findsOneWidget);
    },
  );
}

Trong ví dụ này, app.main() khởi chạy ứng dụng thay vì chỉ tạo một Widget riêng lẻ. Bài kiểm thử sau đó tìm nút có biểu tượng dấu cộng, mô phỏng thao tác nhấn và xác minh giá trị hiển thị đã thay đổi.

Điều kiện để ví dụ hoạt động là ứng dụng trong main.dart phải thực sự có bộ đếm ban đầu bằng 0 và nút Icons.add tăng giá trị lên 1. Nếu giao diện của dự án khác ví dụ này, cần điều chỉnh Finder và kết quả mong đợi cho phù hợp.

Để chạy bài kiểm thử, sử dụng:

flutter test integration_test/app_test.dart

Integration Testing có thể tái sử dụng nhiều kỹ thuật tìm kiếm Widget và mô phỏng thao tác đã học trong Widget Testing. Tuy nhiên, việc khởi chạy ứng dụng thực tế giúp bài kiểm thử bao quát được nhiều thành phần hơn.

3.7. Kiểm thử luồng đăng nhập hoàn chỉnh

Đăng nhập là ví dụ điển hình cho Integration Testing vì chức năng này thường liên quan đến nhiều tầng của ứng dụng.

Một luồng đăng nhập có thể bao gồm:

• Màn hình nhận thông tin tài khoản.

• Form xác thực dữ liệu.

• Lớp xử lý nghiệp vụ gửi yêu cầu.

• API client giao tiếp với backend.

• Máy chủ xác thực tài khoản.

• Lớp quản lý phiên đăng nhập.

• Cơ chế lưu token.

• Router chuyển người dùng sang màn hình chính.

Một bài kiểm thử tích hợp tốt cần xác minh các kết quả quan sát được ở nhiều bước, thay vì chỉ xác minh nút đăng nhập có thể được nhấn.

Ví dụ về kịch bản:

Given:
- Ứng dụng đang ở màn hình đăng nhập.
- Backend thử nghiệm có tài khoản hợp lệ.

When:
- Người dùng nhập email.
- Người dùng nhập mật khẩu.
- Người dùng nhấn nút đăng nhập.
- Ứng dụng hoàn tất yêu cầu xác thực.

Then:
- Không còn hiển thị trạng thái loading.
- Người dùng được chuyển đến màn hình chính.
- Thông tin người dùng được hiển thị chính xác.
- Phiên đăng nhập được duy trì theo thiết kế.

Trong môi trường kiểm thử thực tế, cần chuẩn bị tài khoản thử nghiệm và kiểm soát dữ liệu backend. Nếu bài kiểm thử chạy trực tiếp trên môi trường production, việc tạo tài khoản, thay đổi dữ liệu hoặc đăng nhập có thể gây ra tác động không mong muốn.

Ngoài trường hợp thành công, nên kiểm thử các tình huống như sai mật khẩu, tài khoản không tồn tại, mất kết nối mạng, máy chủ trả về lỗi và token hết hạn.

3.8. Kiểm thử tích hợp API

Trong ứng dụng Flutter, API là cầu nối giữa giao diện và backend. Những lỗi ở ranh giới này có thể khiến chức năng không hoạt động dù giao diện và logic riêng lẻ đều vượt qua kiểm thử.

Ví dụ, ứng dụng bán hàng có thể gọi API lấy danh sách sản phẩm. Các vấn đề có thể phát sinh gồm:

• URL hoặc HTTP method không chính xác.

• Request thiếu tham số.

• Header xác thực không được gửi.

• JSON trả về khác cấu trúc ứng dụng mong đợi.

• Mã trạng thái HTTP không được xử lý đúng.

• Dữ liệu hiển thị không cập nhật sau khi API hoàn tất.

• Lỗi mạng không được chuyển thành trạng thái lỗi phù hợp.

Integration Testing có thể xác minh rằng ứng dụng gửi request, xử lý response và cập nhật giao diện theo đúng luồng nghiệp vụ.

Có hai hướng triển khai thường gặp.

Hướng thứ nhất: sử dụng backend thử nghiệm thật.

Ứng dụng kết nối với máy chủ thử nghiệm, gửi request thực tế và nhận dữ liệu trả về. Hướng này phù hợp khi cần kiểm tra tính tương thích giữa frontend và backend.

Hướng thứ hai: sử dụng dịch vụ giả lập.

Một số dependency như API client hoặc repository được thay thế bằng fake hoặc mock. Hướng này giúp bài kiểm thử ổn định, nhanh hơn và không phụ thuộc vào tình trạng máy chủ bên ngoài.

Cần lựa chọn phương pháp theo mục tiêu. Nếu thay thế toàn bộ tầng API bằng mock, bài kiểm thử không thể chứng minh rằng giao tiếp HTTP thực tế hoạt động đúng.

3.9. Kiểm thử điều hướng giữa nhiều màn hình

Điều hướng là thành phần quan trọng trong ứng dụng Flutter, đặc biệt khi sử dụng Navigator, go_router hoặc các giải pháp routing khác.

Một luồng nghiệp vụ có thể yêu cầu người dùng đi từ màn hình danh sách sản phẩm sang chi tiết sản phẩm, thêm vào giỏ hàng và mở màn hình thanh toán.

Integration Testing có thể xác minh:

• Nhấn một sản phẩm sẽ mở đúng màn hình chi tiết.

• ID sản phẩm được truyền chính xác.

• Nhấn nút quay lại sẽ trở về màn hình phù hợp.

• Dữ liệu giỏ hàng được duy trì giữa các màn hình.

• Người dùng chưa đăng nhập bị chuyển đến màn hình đăng nhập khi cần.

• Sau khi đăng nhập thành công, người dùng được điều hướng đến đúng đích theo thiết kế.

• Deep link mở đúng màn hình và truyền dữ liệu cần thiết.

Những trường hợp này thường khó kiểm tra đầy đủ chỉ bằng một bài kiểm thử Widget độc lập vì hành vi phụ thuộc vào nhiều màn hình và trạng thái được chia sẻ.

3.10. Kiểm thử lưu trữ và dữ liệu giữa các thành phần

Nhiều ứng dụng Flutter cần lưu dữ liệu vào bộ nhớ cục bộ, chẳng hạn thông tin người dùng, tùy chọn giao diện, danh sách yêu thích hoặc dữ liệu giỏ hàng.

Integration Testing có thể kiểm tra chuỗi thao tác lưu và đọc dữ liệu qua các thành phần thực tế.

Ví dụ:

1. Người dùng thêm sản phẩm vào danh sách yêu thích.

2. Ứng dụng lưu trạng thái yêu thích.

3. Người dùng chuyển sang màn hình khác.

4. Người dùng quay lại danh sách sản phẩm.

5. Trạng thái yêu thích vẫn được hiển thị chính xác.

Với dữ liệu cần duy trì sau khi ứng dụng khởi động lại, bài kiểm thử có thể đóng và khởi chạy lại ứng dụng để xác minh dữ liệu được lưu đúng theo yêu cầu.

Đối với các bài kiểm thử sử dụng cơ sở dữ liệu cục bộ hoặc secure storage, cần chuẩn bị và dọn dẹp dữ liệu trước hoặc sau mỗi lần chạy. Điều này giúp hạn chế trường hợp kết quả của bài kiểm thử trước ảnh hưởng đến bài kiểm thử sau.

3.11. Giới hạn của Integration Testing

Integration Testing có phạm vi rộng hơn Widget Testing nhưng cũng có những hạn chế riêng.

• Thời gian chạy thường lâu hơn do phải khởi tạo ứng dụng và môi trường thực thi.

• Có thể phụ thuộc vào thiết bị, trình giả lập, backend hoặc mạng.

• Việc thiết lập dữ liệu kiểm thử phức tạp hơn.

• Lỗi có thể khó xác định chính xác nằm ở giao diện, logic nghiệp vụ hay tầng dữ liệu.

• Bài kiểm thử dễ mất ổn định nếu phụ thuộc vào thời gian xử lý không được kiểm soát.

• Chạy trên trình giả lập không đảm bảo mọi hành vi giống hoàn toàn thiết bị thật.

• Một số vấn đề liên quan đến hệ điều hành, phần cứng hoặc hiệu năng vẫn cần được kiểm tra riêng.

Vì vậy, Integration Testing không nên được dùng thay thế toàn bộ Unit Testing và Widget Testing. Nếu mọi trường hợp đều được kiểm tra bằng những bài kiểm thử tích hợp lớn, thời gian chạy và chi phí bảo trì có thể tăng đáng kể.

4. So sánh Widget Testing và Integration Testing

Hai phương pháp cùng hướng đến việc nâng cao chất lượng ứng dụng nhưng khác nhau về phạm vi, môi trường chạy và mục tiêu kiểm tra.

Một ví dụ giúp phân biệt rõ hơn là chức năng thêm sản phẩm vào giỏ hàng.

• Widget Testing kiểm tra nút thêm vào giỏ hàng có thể được nhấn và số lượng hiển thị thay đổi chính xác.

• Integration Testing kiểm tra người dùng mở sản phẩm, thêm vào giỏ hàng, chuyển đến màn hình giỏ hàng và nhìn thấy đúng sản phẩm cùng số lượng.

Cả hai bài kiểm thử đều có giá trị, nhưng mỗi bài xác minh một phạm vi khác nhau.

5. Mối quan hệ giữa Unit Testing, Widget Testing và Integration Testing

Trong một dự án Flutter, ba cấp độ kiểm thử thường được phối hợp để tạo thành một hệ thống kiểm thử nhiều lớp.

5.1. Unit Testing

Unit Testing tập trung vào một đơn vị logic nhỏ, thường là một hàm, phương thức hoặc lớp được cô lập khỏi các dependency không cần thiết.

Ví dụ, hàm tính tổng tiền của giỏ hàng có thể được kiểm thử bằng nhiều bộ dữ liệu mà không cần mở giao diện hoặc kết nối máy chủ.

double calculateTotal(
  double price,
  int quantity,
) {
  return price * quantity;
}

Bài kiểm thử có thể xác minh kết quả với số lượng bằng 0, 1 hoặc nhiều sản phẩm.

5.2. Widget Testing

Widget Testing kiểm tra cách giao diện hiển thị kết quả và phản hồi khi trạng thái thay đổi. Ví dụ, khi tổng tiền thay đổi, Widget hiển thị giá trị mới chính xác.

5.3. Integration Testing

Integration Testing xác minh rằng toàn bộ quy trình từ chọn sản phẩm, thêm vào giỏ hàng đến hiển thị tổng tiền hoạt động đúng khi các thành phần được kết nối với nhau.

Ba cấp độ tạo thành một hệ thống bổ trợ lẫn nhau. Unit Testing giúp xác minh logic cốt lõi, Widget Testing xác minh giao diện và Integration Testing xác minh sự phối hợp giữa các thành phần.

6. Quy trình triển khai kiểm thử trong dự án Flutter

6.1. Xác định yêu cầu kiểm thử

Trước khi viết test, cần xác định chức năng nào có rủi ro cao và những kết quả cần được đảm bảo.

Đối với ứng dụng thương mại điện tử, các chức năng quan trọng có thể bao gồm:

• Đăng nhập và đăng ký.

• Tìm kiếm sản phẩm.

• Thêm, xóa và cập nhật giỏ hàng.

• Tính tổng tiền.

• Áp dụng mã giảm giá.

• Đặt hàng và thanh toán.

• Quản lý hồ sơ người dùng.

Mỗi chức năng cần được phân chia thành các trường hợp kiểm thử nhỏ, xác định dữ liệu đầu vào và kết quả mong đợi.

6.2. Thiết kế bài kiểm thử theo hành vi

Nên tập trung vào những hành vi mà người dùng có thể quan sát được.

Ví dụ, thay vì chỉ kiểm tra một biến nội bộ đã thay đổi, hãy xác minh rằng số lượng sản phẩm trên giao diện đã được cập nhật và tổng tiền phản ánh chính xác số lượng mới.

Cách tiếp cận này giúp bài kiểm thử ít phụ thuộc vào chi tiết triển khai, từ đó giảm chi phí sửa đổi khi cấu trúc bên trong được thay đổi.

6.3. Chuẩn bị dữ liệu kiểm thử

Dữ liệu cần được thiết lập rõ ràng và nhất quán.

Đối với Widget Testing, có thể sử dụng dữ liệu mẫu hoặc fake repository. Đối với Integration Testing, cần xác định backend, tài khoản, cơ sở dữ liệu và các dependency nào sẽ được sử dụng thật.

Mỗi bài kiểm thử nên tránh phụ thuộc vào dữ liệu được tạo ngẫu nhiên hoặc kết quả còn sót lại từ những lần chạy trước.

6.4. Chạy kiểm thử thường xuyên

Trong quá trình phát triển, nên chạy những bài kiểm thử phù hợp sau khi thay đổi code.

Ví dụ:

# Chạy toàn bộ kiểm thử trong thư mục test
flutter test

# Chạy một file Widget Testing
flutter test test/widgets/counter_button_test.dart

# Chạy một file Integration Testing
flutter test integration_test/app_test.dart

Đường dẫn file cần tương ứng với cấu trúc thực tế của dự án.

Khi một bài kiểm thử thất bại, cần phân biệt giữa lỗi của ứng dụng và lỗi trong chính bài kiểm thử. Một test có thể thất bại vì kết quả mong đợi không còn đúng, dữ liệu chưa được chuẩn bị hoặc thao tác bất đồng bộ chưa hoàn tất.

6.5. Tích hợp kiểm thử vào CI/CD

Với dự án làm việc nhóm, có thể cấu hình CI để tự động chạy kiểm thử mỗi khi tạo pull request hoặc cập nhật nhánh chính.

Thông thường, Unit Testing và Widget Testing có thể được chạy ở giai đoạn sớm vì thời gian thực thi tương đối ngắn. Integration Testing có thể được chạy trên runner được cấu hình thiết bị hoặc trình giả lập phù hợp.

Một pipeline cơ bản có thể bao gồm:

1. Kiểm tra định dạng code bằng dart format.

2. Phân tích code bằng flutter analyze.

3. Chạy Unit Testing và Widget Testing.

4. Khởi tạo môi trường thiết bị cho Integration Testing.

5. Chạy các luồng nghiệp vụ quan trọng.

6. Tổng hợp kết quả và báo lỗi nếu có bài kiểm thử thất bại.

Không phải mọi dự án đều cần chạy toàn bộ Integration Testing sau mỗi lần thay đổi nhỏ. Có thể lựa chọn tập kiểm thử phù hợp với thời gian build, tài nguyên và mức độ rủi ro.

7. Các nguyên tắc viết Widget Testing và Integration Testing hiệu quả

7.1. Ưu tiên kiểm tra hành vi quan trọng

Không cần kiểm thử mọi chi tiết nhỏ của giao diện. Nên ưu tiên các hành vi ảnh hưởng đến chức năng và trải nghiệm người dùng.

Một nút có màu nền cụ thể có thể không cần nhiều bài kiểm thử nếu màu sắc không phải yêu cầu quan trọng. Ngược lại, nút thanh toán cần được kiểm tra kỹ về trạng thái cho phép nhấn, xử lý khi gửi yêu cầu và phản hồi khi thanh toán thất bại.

7.2. Tránh phụ thuộc vào thời gian cố định

Các thao tác bất đồng bộ có thể hoàn tất ở những thời điểm khác nhau. Không nên mặc định rằng một khoảng thời gian chờ tùy ý luôn đủ để hoàn thành thao tác.

Trong Widget Testing, có thể sử dụng pump() với khoảng thời gian phù hợp hoặc pumpAndSettle() khi cần chờ giao diện ổn định. Với Integration Testing, cần kiểm soát điều kiện hoàn tất và tránh những khoảng chờ dài không cần thiết.

7.3. Tách dependency để dễ kiểm soát

Các thành phần như API client, repository và dịch vụ lưu trữ nên được thiết kế sao cho có thể thay thế trong môi trường kiểm thử.

Điều này giúp kiểm tra giao diện với nhiều tình huống khác nhau mà không phải phụ thuộc hoàn toàn vào hệ thống bên ngoài.

Tuy nhiên, cần duy trì một số bài kiểm thử tích hợp thực sự kết nối các thành phần quan trọng. Nếu mọi dependency đều được thay thế bằng mock, các lỗi tích hợp thật có thể không được phát hiện.

7.4. Đặt tên test rõ ràng

Tên bài kiểm thử nên thể hiện điều kiện và kết quả mong đợi.

Ví dụ:

testWidgets(
  'Shows validation error when email is empty',
  (tester) async {
    // Arrange, act, assert
  },
);

Tên rõ ràng giúp lập trình viên nhanh chóng hiểu nguyên nhân khi test thất bại.

7.5. Kiểm tra cả trường hợp thành công và thất bại

Một chức năng không thể được xem là đáng tin cậy chỉ vì hoạt động tốt trong trường hợp lý tưởng.

Đối với chức năng đăng nhập, cần kiểm tra cả tài khoản hợp lệ, mật khẩu sai, dữ liệu trống và lỗi mạng. Đối với giỏ hàng, cần kiểm tra số lượng hợp lệ, sản phẩm hết hàng và trường hợp dữ liệu không đồng nhất.

7.6. Dọn dẹp trạng thái sau kiểm thử

Các bài kiểm thử không nên ảnh hưởng lẫn nhau. Nếu một bài kiểm thử thêm sản phẩm vào cơ sở dữ liệu, bài tiếp theo cần có môi trường dữ liệu được chuẩn bị phù hợp.

Việc khôi phục trạng thái giúp kết quả có tính ổn định và dễ tái hiện khi chạy trên máy lập trình viên hoặc hệ thống CI.

8. Các lỗi thường gặp khi triển khai kiểm thử

Một số vấn đề phổ biến trong quá trình viết test Flutter gồm:

Không tìm thấy Widget: Có thể do Widget chưa được tạo, nội dung hiển thị khác dự kiến hoặc giao diện chưa được cập nhật. Cần kiểm tra Finder và trạng thái cây Widget.

Kết quả không thay đổi sau thao tác: Có thể do callback không được gọi, thao tác chưa hoàn tất hoặc bài kiểm thử chưa cập nhật frame bằng pump().

Test timeout: Thường liên quan đến tác vụ bất đồng bộ, animation chưa kết thúc hoặc điều kiện chờ không phù hợp.

Lỗi do thiếu môi trường: Widget có thể cần MaterialApp, Navigator, Theme hoặc dependency mà bài kiểm thử chưa cung cấp.

Integration Testing thất bại khi chạy trên thiết bị: Cần kiểm tra thiết bị có được nhận diện hay không, ứng dụng có khởi chạy thành công không, backend có truy cập được không và cấu hình môi trường có đúng không.

Test phụ thuộc vào dữ liệu cũ: Có thể xảy ra khi dữ liệu cục bộ hoặc dữ liệu backend không được làm sạch giữa các lần chạy.

Test dễ hỏng khi thay đổi giao diện: Thường do bài kiểm thử phụ thuộc quá nhiều vào cấu trúc nội bộ hoặc các chuỗi văn bản không ổn định. Có thể sử dụng Key cho những thành phần cần định danh rõ ràng.

9. Ví dụ áp dụng trong dự án thương mại điện tử Flutter

Đối với một ứng dụng bán hàng, có thể phân chia kiểm thử theo từng chức năng như sau.

Với cách phân chia này, nhóm phát triển có thể xác định rõ mục tiêu của từng bài kiểm thử, tránh việc nhiều bài test kiểm tra trùng lặp nhưng vẫn bỏ sót những luồng quan trọng.

10. Kết luận

Widget Testing và Integration Testing là hai thành phần quan trọng trong quy trình phát triển ứng dụng Flutter chất lượng cao.

Widget Testing giúp kiểm tra giao diện, trạng thái và hành vi của một Widget hoặc nhóm Widget trong môi trường được kiểm soát. Đây là lựa chọn phù hợp để phát hiện nhanh các lỗi liên quan đến hiển thị và tương tác.

Integration Testing giúp xác minh khả năng phối hợp giữa nhiều thành phần trong ứng dụng, từ giao diện, logic nghiệp vụ đến API, lưu trữ và điều hướng. Phương pháp này đặc biệt hữu ích đối với các luồng nghiệp vụ quan trọng như đăng nhập, quản lý giỏ hàng và đặt hàng.

Trong thực tế, không nên lựa chọn một trong hai phương pháp để thay thế phương pháp còn lại. Một chiến lược kiểm thử hiệu quả cần kết hợp Unit Testing, Widget Testing và Integration Testing theo phạm vi phù hợp. Khi được thiết kế tốt, hệ thống kiểm thử tự động giúp phát hiện lỗi sớm, giảm rủi ro khi refactor, tăng độ tin cậy của sản phẩm và hỗ trợ nhóm phát triển duy trì chất lượng ứng dụng trong suốt vòng đời dự án.