Kiểm thử có thể kết hợp: Góc nhìn mới của Kent Beck về thiết kế test hiệu quả

Kent Beck, một trong những nhân vật có ảnh hưởng nhất trong lĩnh vực kỹ thuật phần mềm, vừa đăng tải một bài viết quan trọng trên blog cá nhân của mình. Trong bài viết, ông giải thích chi tiết về khái niệm Composable Tests (Kiểm thử có thể kết hợp), một ý tưởng có thể thay đổi cách các lập trình viên nhìn nhận về bộ kiểm thử của mình.

Bài viết xoay quanh hai đặc tính quan trọng mà một bộ kiểm thử cần có: Isolation (tính cô lập) và Composition (tính kết hợp). Kent Beck cho rằng, mặc dù chúng có vẻ giống nhau, nhưng thực chất lại là hai khái niệm khác biệt, và việc hiểu rõ sự khác biệt này có thể giúp các nhà phát triển tạo ra những bộ test vừa nhanh hơn, vừa dễ đọc hơn và dễ bảo trì hơn.

Isolation (Tính cô lập) là gì?

Theo định nghĩa của Kent Beck, một test được gọi là "cô lập" khi nó tự thiết lập toàn bộ dữ liệu đầu vào (test fixture) từ đầu cho mỗi lần chạy. Điều này có nghĩa là thứ tự chạy các test không ảnh hưởng đến kết quả cuối cùng.

"Nếu một test bắt đầu bằng việc tự tạo ra fixture cho riêng mình, tạo từ đầu toàn bộ dữ liệu nó sẽ sử dụng, thì test đó được đảm bảo là cô lập."

Điều này tương tự như khái niệm referential transparency trong lập trình hàm - cùng một đầu vào sẽ luôn cho cùng một đầu ra.

Hầu hết các framework kiểm thử theo phong cách xUnit đều khuyến khích tính cô lập này bằng cách tạo một instance mới của class test cho mỗi test case và chạy hàm setUp() trước mỗi test.

Composition (Tính kết hợp) - điểm mấu chốt

Khác với Isolation, Composition nói về việc khi chạy toàn bộ các test lại với nhau như một bộ, sự thành công của cả bộ test sẽ mang lại sự tự tin lớn hơn cho nhà phát triển, ngay cả khi mỗi test riêng lẻ không bao quát được toàn bộ chức năng.

Kent Beck đã đưa ra một ví dụ rất điển hình:

test1()
  object := new Whatever()
  actual := object.doSomething()
  assertEquals(expected, actual)

test2()
  object := new Whatever()
  actual := object.doSomething()
  assertEquals(expected, actual)
  actual2 := object.nowSomethingElse()
  assertEquals(expected2, actual2)

Vấn đề ở đây là test2 chứa toàn bộ logic của test1, dẫn đến sự trùng lặp không cần thiết.

"Tôi đã từng thấy những test được copy-paste và mở rộng lên đến 6 hoặc 7 lần. Test cuối cùng đọc rất khó hiểu."

Khi đối mặt với tình huống này, chúng ta có 3 lựa chọn:

• Giữ cả hai test: Điều này khiến bộ test bị thừa thãi, không cần thiết.
• Xóa test1: Mất đi tính đặc hiệu (specificity) - khi test thất bại, bạn không biết chính xác vấn đề nằm ở đâu.
• Đơn giản hóa test2: Đây là giải pháp được Kent Beck ưu tiên nhất.

Giải pháp tối ưu: Kết hợp thông minh

Kent Beck đề xuất việc tỉa bớt (pruning) test2 để loại bỏ những phần trùng lặp không cần thiết:

test2()
  object := new Whatever()
  object.doSomething()
  actual := object.nowSomethingElse()
  assertEquals(expected, actual)

Bằng cách này, sự kết hợp của test1 và test2 không làm mất đi tính dự đoán (predictive) hay tính đặc hiệu (specific) của bộ test. Trên thực tế, sự kết hợp còn có thể giúp bộ test chính xác hơn, vì có khả năng test1 thất bại trong khi test2 vẫn vượt qua.

Chiến lược N x M

Một trong những ví dụ thuyết phục nhất mà Kent Beck đưa ra là chiến lược kiểm thử cho các hệ thống có nhiều biến thể. Giả sử chúng ta có:

• 4 cách tính lãi suất
• 5 cách báo cáo lãi suất

Cách tiếp cận "manually brute force" sẽ tạo ra 20 test (4 x 5). Tuy nhiên, với chiến lược kết hợp thông minh, chúng ta chỉ cần:

• 4 test cho phần tính toán
• 5 test cho phần báo cáo
• 1 test kết hợp cả hai để chứng minh chúng được kết nối đúng cách

Tổng cộng chỉ cần 10 test thay vì 20 test, mà vẫn đạt được độ tin cậy tương đương.

"Việc đạt được sự tự tin từ các test kết hợp đòi hỏi sự suy nghĩ, suy luận và thiết kế kỹ lưỡng, nhưng khoản đầu tư này sẽ được đền bù xứng đáng"

Những lợi ích rõ rệt

Theo Kent Beck, việc áp dụng Chiến lược kết hợp (Composable Tests) mang lại những lợi ích vượt trội:

• Nhanh hơn: Ít test hơn đồng nghĩa với việc thời gian chạy test ngắn hơn.
• Dễ đọc hơn: Mỗi test chỉ tập trung vào một khía cạnh cụ thể.
• Dễ thay đổi hơn: Việc sửa đổi logic nghiệp vụ không yêu cầu sửa quá nhiều test.
• Đặc hiệu hơn: Khi test thất bại, việc xác định nguyên nhân trở nên dễ dàng hơn.
• Ít nhạy cảm với thay đổi cấu trúc: Các test không bị "dính chặt" vào cấu trúc nội bộ của mã nguồn.

Lời chỉ trích và phản hồi

Kent Beck cũng thẳng thắn phản hồi những chỉ trích mà ông nhận được từ cộng đồng phát triển phần mềm:

"Khi tôi giải thích về khái niệm này, tôi thường nhận được phản ứng sốc từ những developer có kinh nghiệm. Họ thường nói: 'Tôi sẽ không bao giờ giảm bớt các assertion trong một test.'"

Ông cho rằng phản ứng này xuất phát từ nỗi sợ hãi chứ không phải từ nguyên tắc.

"Composition không làm cho test trở nên tệ hơn. Composition là nhìn vào bộ test như một tổng thể và cố gắng làm cho tổng thể đó tốt hơn dựa trên nhiều đặc tính có giá trị của test."

Kết luận

Bài viết của Kent Beck về Composable Tests là một đóng góp quý giá cho cộng đồng lập trình viên. Nó nhắc nhở chúng ta rằng, giống như việc thiết kế mã nguồn, việc thiết kế các bài test cũng cần sự tư duy và chiến lược. Việc chạy đua theo số lượng test để đạt chỉ tiêu "độ phủ code" không phải lúc nào cũng là giải pháp tốt nhất. Thay vào đó, hãy tập trung vào việc xây dựng một bộ test thông minh, có khả năng kết hợp, vừa dễ bảo trì vừa mang lại giá trị thực sự cho dự án.

Đối với các lập trình viên Việt Nam, nhất là những người mới bắt đầu học về kiểm thử, bài viết này là một lời nhắc nhở quan trọng: Hãy viết test như một nghệ thuật, không phải một thủ tục. Thay vì cố gắng thêm càng nhiều assertion càng tốt, hãy tập trung vào việc thiết kế các test có khả năng kết hợp với nhau để tạo nên một bộ kiểm thử mạnh mẽ và hiệu quả.

Bài viết được dịch và tổng hợp từ blog của Kent Beck, người sáng lập ra Extreme Programming và là một trong những tác giả của cuốn sách kinh điển "Test-Driven Development: By Example".