Vì sao kiểm thử tự động là khoản đầu tư đáng giá cho mọi đội phát triển
Trong nhiều dự án, kiểm thử tự động bị xem như công việc phụ, thứ làm sau cùng nếu còn thời gian. Nhưng những đội trưởng thành nhất lại coi nó là một phần không thể tách rời của quá trình viết phần mềm. Lý do rất thực dụng: phần mềm luôn thay đổi, và mỗi thay đổi đều mang theo rủi ro phá vỡ thứ đang chạy tốt. Bộ kiểm thử tự động chính là tấm lưới an toàn giúp đội phát triển dám thay đổi nhanh mà không sợ hãi.
Kiểm thử là lưới an toàn cho sự thay đổi
Hãy tưởng tượng bạn cần sửa một hàm tính giá đơn hàng có khuyến mãi. Nếu không có kiểm thử, bạn phải tự tay thử lại hàng loạt trường hợp: đơn thường, đơn có mã giảm giá, đơn vượt ngưỡng miễn phí vận chuyển, đơn bị lỗi. Việc này tốn thời gian và dễ bỏ sót. Với một bộ kiểm thử tốt, bạn chỉ cần chạy lệnh và trong vài giây biết ngay thay đổi của mình có làm hỏng hành vi nào không. Tốc độ phản hồi này thay đổi hoàn toàn cách làm việc, biến nỗi lo thành sự tự tin.
Điều quan trọng cần hiểu là giá trị của kiểm thử không nằm ở việc chứng minh code đúng ở thời điểm viết, mà ở việc bảo vệ code khỏi hồi quy trong tương lai. Một lỗi đã từng được sửa và có kiểm thử đi kèm sẽ rất khó quay lại, vì bất kỳ ai vô tình tái tạo lỗi đó sẽ bị bộ kiểm thử chặn ngay lập tức.
Kim tự tháp kiểm thử và sự cân bằng
Không phải mọi loại kiểm thử đều giống nhau. Mô hình kim tự tháp kiểm thử gợi ý một sự phân bổ hợp lý giữa các tầng. Ở đáy là kiểm thử đơn vị, kiểm tra từng hàm hay lớp nhỏ một cách độc lập; chúng chạy cực nhanh và nên chiếm số lượng lớn nhất. Ở giữa là kiểm thử tích hợp, xác minh rằng các thành phần phối hợp đúng, chẳng hạn tầng dịch vụ làm việc đúng với cơ sở dữ liệu thật. Trên đỉnh là kiểm thử đầu cuối, mô phỏng hành vi người dùng qua toàn bộ hệ thống; chúng quý giá nhưng chậm và dễ vỡ, nên cần giữ số lượng ở mức tối thiểu hợp lý.
- Kiểm thử đơn vị: nhanh, nhiều, tập trung vào logic nghiệp vụ cốt lõi.
- Kiểm thử tích hợp: vừa phải, xác minh ranh giới giữa các module và dịch vụ bên ngoài.
- Kiểm thử đầu cuối: ít, chỉ phủ những luồng quan trọng nhất như đăng nhập hay thanh toán.
Khi kim tự tháp bị lật ngược, tức là quá nhiều kiểm thử đầu cuối và quá ít kiểm thử đơn vị, đội sẽ phải chịu đựng những lần chạy chậm chạp và những lần thất bại không rõ nguyên nhân. Cân bằng đúng giúp bộ kiểm thử vừa nhanh vừa đáng tin.
Một bài kiểm thử tốt trông như thế nào
Một bài kiểm thử có giá trị phải rõ ràng về ý định. Cấu trúc phổ biến và hiệu quả là sắp xếp, thực thi, khẳng định: chuẩn bị dữ liệu đầu vào, gọi hàm cần kiểm tra, rồi so sánh kết quả với kỳ vọng. Tên bài kiểm thử nên mô tả hành vi được kiểm tra, ví dụ trả về lỗi khi số dư không đủ, để khi nó thất bại bạn biết ngay điều gì đã hỏng mà không cần đọc nội dung.
Bài kiểm thử cũng nên độc lập với nhau và không phụ thuộc thứ tự chạy. Mỗi bài tự thiết lập trạng thái cần thiết và dọn dẹp sau khi xong. Tránh để các bài kiểm thử chia sẻ trạng thái toàn cục, vì điều đó tạo ra những thất bại ngẫu nhiên khó truy vết. Ngoài ra, hãy kiểm tra cả những trường hợp biên: giá trị rỗng, số âm, danh sách trống, đầu vào cực lớn. Lỗi thường ẩn nấp ở những vùng biên này.
Đừng theo đuổi độ phủ tuyệt đối
Độ phủ kiểm thử là một con số dễ đo nhưng dễ bị hiểu sai. Đạt một trăm phần trăm độ phủ không có nghĩa là không còn lỗi, vì độ phủ chỉ cho biết dòng nào được chạy chứ không cho biết hành vi nào được khẳng định đúng. Một đội có thể có độ phủ rất cao nhưng các khẳng định lại hời hợt. Thay vì chạy theo con số, hãy đầu tư kiểm thử vào những phần có logic phức tạp, những phần thường thay đổi và những phần mà lỗi gây hậu quả nghiêm trọng.
Tóm lại, kiểm thử tự động không làm chậm đội phát triển như nhiều người lo ngại; ngược lại, về dài hạn nó giải phóng đội khỏi nỗi sợ thay đổi và những đêm thức trắng sửa lỗi sản xuất. Hãy bắt đầu nhỏ, viết kiểm thử cho phần dễ vỡ nhất trước, và để thói quen đó lớn dần thành văn hóa kỹ thuật của cả đội.
