Xác định những gì bạn cần kiểm thử và những gì bạn có thể loại trừ.
Bài viết trước đã đề cập đến các kiến thức cơ bản về trường hợp kiểm thử và nội dung cần có trong trường hợp kiểm thử. Bài viết này đi sâu hơn vào việc tạo trường hợp kiểm thử từ góc độ kỹ thuật, trình bày chi tiết những nội dung cần đưa vào mỗi lần kiểm thử và những điều cần tránh. Về cơ bản, bạn sẽ tìm hiểu câu trả lời cho những câu hỏi muôn thuở như "Nên kiểm thử gì" hoặc "Không nên kiểm thử gì".
Nguyên tắc chung và mẫu
Xin lưu ý rằng các mẫu và điểm cụ thể là rất quan trọng, bất kể bạn đang tiến hành kiểm thử đơn vị, tích hợp hay toàn diện. Bạn có thể và nên áp dụng các nguyên tắc này cho cả hai loại kiểm thử, vì vậy, đây là một điểm khởi đầu phù hợp.
Luôn đơn giản
Khi viết mã kiểm thử, một trong những điều quan trọng nhất cần nhớ là phải đơn giản. Điều quan trọng là phải cân nhắc dung lượng của bộ não. Mã sản xuất chính chiếm nhiều dung lượng, khiến bạn không có nhiều không gian để thêm độ phức tạp. Điều này đặc biệt đúng khi kiểm thử.
Nếu có ít không gian hơn, bạn có thể thư giãn hơn trong quá trình kiểm thử. Đó là lý do tại sao bạn cần ưu tiên sự đơn giản trong quá trình kiểm thử. Trên thực tế, các phương pháp hay nhất về kiểm thử JavaScript của Yoni Goldberg nhấn mạnh tầm quan trọng của Quy tắc vàng – quy tắc này cho thấy kiểm thử của bạn giống như một trợ lý chứ không phải một công thức toán học phức tạp. Nói cách khác, bạn phải có thể hiểu được ý định của kiểm thử ngay từ cái nhìn đầu tiên.
Bạn nên hướng đến sự đơn giản trong tất cả các loại kiểm thử, bất kể độ phức tạp của các loại kiểm thử đó. Trên thực tế, quy trình kiểm thử càng phức tạp thì càng cần đơn giản hoá. Một cách để đạt được điều này là thông qua thiết kế kiểm thử phẳng, trong đó các kiểm thử được giữ càng đơn giản càng tốt và chỉ kiểm thử những gì cần thiết. Điều này có nghĩa là mỗi kiểm thử chỉ nên chứa một trường hợp kiểm thử và trường hợp kiểm thử đó phải tập trung vào việc kiểm thử một chức năng hoặc tính năng cụ thể.
Hãy suy nghĩ về vấn đề này theo cách sau: bạn phải dễ dàng xác định được vấn đề khi đọc một kiểm thử không thành công. Đó là lý do tại sao bạn cần phải giữ cho mã kiểm thử đơn giản và dễ hiểu. Việc này giúp bạn nhanh chóng xác định và khắc phục vấn đề khi chúng phát sinh.
Thử nghiệm những nội dung đáng giá
Thiết kế kiểm thử phẳng cũng khuyến khích sự tập trung và giúp đảm bảo các kiểm thử của bạn có ý nghĩa. Hãy nhớ rằng bạn không nên tạo kiểm thử chỉ để tăng mức độ bao phủ – các kiểm thử phải luôn có mục đích.
Không kiểm thử thông tin chi tiết về việc triển khai
Một vấn đề thường gặp trong quá trình kiểm thử là các bài kiểm thử thường được thiết kế để kiểm thử thông tin chi tiết về việc triển khai, chẳng hạn như sử dụng bộ chọn trong các thành phần hoặc kiểm thử toàn diện. Thông tin chi tiết về việc triển khai đề cập đến những điều mà người dùng mã của bạn thường không sử dụng, xem hoặc thậm chí không biết. Điều này có thể dẫn đến hai vấn đề lớn trong kiểm thử: âm tính giả và dương tính giả.
Kết quả âm tính giả xảy ra khi kiểm thử không thành công, mặc dù mã được kiểm thử là chính xác. Điều này có thể xảy ra khi chi tiết triển khai thay đổi do tái cấu trúc mã ứng dụng. Mặt khác, kết quả dương tính giả xảy ra khi kiểm thử thành công, mặc dù mã đang được kiểm thử không chính xác.
Một giải pháp cho vấn đề này là cân nhắc các loại người dùng mà bạn có. Người dùng cuối và nhà phát triển có thể khác nhau về phương pháp và cách tương tác với mã. Khi lập kế hoạch kiểm thử, điều quan trọng là phải xem xét những nội dung mà người dùng sẽ nhìn thấy hoặc tương tác, đồng thời làm cho các bài kiểm thử phụ thuộc vào những nội dung đó thay vì thông tin triển khai chi tiết.
Ví dụ: việc chọn bộ chọn ít thay đổi hơn có thể giúp kiểm thử trở nên đáng tin cậy hơn: thuộc tính-dữ liệu thay vì bộ chọn CSS. Để biết thêm thông tin chi tiết, hãy tham khảo Kent C. bài viết của Dodds về chủ đề này hoặc hãy chú ý theo dõi – chúng tôi sẽ sớm ra mắt một bài viết về chủ đề này.
Mô phỏng: Đừng mất quyền kiểm soát
Mô phỏng là một khái niệm rộng được dùng trong kiểm thử đơn vị và đôi khi trong kiểm thử tích hợp. Phương pháp này liên quan đến việc tạo dữ liệu hoặc thành phần giả để mô phỏng các phần phụ thuộc có toàn quyền kiểm soát ứng dụng. Điều này cho phép kiểm thử riêng biệt.
Việc sử dụng mô phỏng trong kiểm thử có thể cải thiện khả năng dự đoán, phân tách các mối quan tâm và hiệu suất. Ngoài ra, nếu cần tiến hành kiểm thử cần có sự tham gia của con người (chẳng hạn như xác minh hộ chiếu), bạn sẽ phải che giấu kiểm thử đó bằng cách sử dụng mô phỏng. Vì tất cả những lý do này, mô phỏng là một công cụ có giá trị mà bạn nên cân nhắc.
Đồng thời, việc mô phỏng có thể ảnh hưởng đến độ chính xác của kiểm thử vì đó là mô phỏng, chứ không phải trải nghiệm thực tế của người dùng. Vì vậy, bạn cần lưu ý khi sử dụng mô phỏng và mô hình.
Bạn có nên mô phỏng trong kiểm thử toàn diện không?
Nói chung là không. Tuy nhiên, đôi khi việc mô phỏng có thể giúp ích cho bạn rất nhiều. Vì vậy, đừng loại bỏ hoàn toàn tính năng này.
Hãy tưởng tượng trường hợp sau: bạn đang viết mã kiểm thử cho một tính năng liên quan đến dịch vụ của nhà cung cấp dịch vụ thanh toán bên thứ ba. Bạn đang ở trong môi trường hộp cát mà họ cung cấp, nghĩa là không có giao dịch thực nào đang diễn ra. Rất tiếc, hộp cát đang hoạt động không đúng cách, do đó khiến các bài kiểm thử của bạn không thành công. Nhà cung cấp dịch vụ thanh toán cần khắc phục vấn đề này. Bạn chỉ có thể chờ nhà cung cấp giải quyết vấn đề.
Trong trường hợp này, bạn nên giảm bớt sự phụ thuộc vào các dịch vụ mà bạn không thể kiểm soát. Bạn vẫn nên sử dụng tính năng mô phỏng một cách thận trọng trong các kiểm thử tích hợp hoặc kiểm thử toàn diện vì tính năng này làm giảm mức độ tin cậy của các kiểm thử.
Thông tin cụ thể về kiểm thử: Những việc nên làm và không nên làm
Tóm lại, một bài kiểm thử chứa những gì? Các loại kiểm thử có gì khác biệt không? Hãy cùng tìm hiểu kỹ hơn về một số khía cạnh cụ thể phù hợp với các loại kiểm thử chính.
Kiểm thử đơn vị tốt là gì?
Một kiểm thử đơn vị lý tưởng và hiệu quả phải:
- Tập trung vào các khía cạnh cụ thể.
- Hoạt động độc lập.
- Bao gồm các trường hợp quy mô nhỏ.
- Sử dụng tên mô tả.
- Làm theo mẫu AAA nếu có.
- Đảm bảo phạm vi kiểm thử toàn diện.
| Nên ✅ | Không nên ❌ |
|---|---|
| Giữ cho các bài kiểm thử càng nhỏ càng tốt. Kiểm thử một khía cạnh cho mỗi trường hợp kiểm thử. | Viết mã kiểm thử trên các đơn vị lớn. |
| Luôn tách biệt các bài kiểm thử và mô phỏng những thứ bạn cần nằm ngoài đơn vị. | Bao gồm các thành phần hoặc dịch vụ khác. |
| Giữ cho các bài kiểm thử độc lập. | Dựa vào các lần kiểm thử trước đó hoặc chia sẻ dữ liệu kiểm thử. |
| Cung cấp nhiều tình huống và lộ trình. | Giới hạn bản thân ở lộ trình phù hợp hoặc kiểm thử âm tính ở mức tối đa. |
| Sử dụng tiêu đề kiểm thử mô tả để bạn có thể biết ngay nội dung kiểm thử. | Chỉ kiểm thử theo tên hàm, kết quả là không đủ mô tả: testBuildFoo() hoặc testGetId(). |
| Hãy hướng đến mức độ sử dụng mã tốt hoặc phạm vi trường hợp kiểm thử rộng hơn, đặc biệt là ở giai đoạn này. | Kiểm thử từ mọi lớp xuống cấp cơ sở dữ liệu (I/O). |
Kiểm thử tích hợp tốt là kiểm thử như thế nào?
Một kiểm thử tích hợp lý tưởng cũng có một số tiêu chí giống với kiểm thử đơn vị. Tuy nhiên, bạn cần cân nhắc thêm một số điểm sau. Một kiểm thử tích hợp hiệu quả phải:
- Mô phỏng hoạt động tương tác giữa các thành phần.
- Bao gồm các tình huống thực tế và sử dụng mô phỏng hoặc mô hình.
- Cân nhắc hiệu suất.
| Nên ✅ | Không nên ❌ |
|---|---|
| Kiểm thử các điểm tích hợp: xác minh rằng mỗi đơn vị hoạt động tốt với nhau khi được tích hợp với nhau. | Kiểm thử từng đơn vị riêng biệt – đó là mục đích của kiểm thử đơn vị. |
| Kiểm thử các tình huống thực tế: sử dụng dữ liệu kiểm thử bắt nguồn từ dữ liệu thực tế. | Sử dụng dữ liệu kiểm thử được tạo tự động lặp đi lặp lại hoặc dữ liệu khác không phản ánh các trường hợp sử dụng thực tế. |
| Sử dụng mô phỏng và mô hình con cho các phần phụ thuộc bên ngoài để duy trì quyền kiểm soát toàn bộ quá trình kiểm thử. | Tạo phần phụ thuộc trên các dịch vụ của bên thứ ba, ví dụ: các yêu cầu mạng đến các dịch vụ bên ngoài. |
| Sử dụng quy trình dọn dẹp trước và sau mỗi lần kiểm thử. | Quên sử dụng các biện pháp dọn dẹp bên trong kiểm thử, nếu không, điều này có thể dẫn đến kiểm thử không thành công hoặc dương tính giả do thiếu tính năng tách biệt kiểm thử thích hợp. |
Kiểm thử toàn diện tốt là kiểm thử như thế nào?
Một quy trình kiểm thử toàn diện từ đầu đến cuối phải:
- Sao chép hoạt động tương tác của người dùng.
- Bao gồm các trường hợp quan trọng.
- Trải dài trên nhiều lớp.
- Quản lý các thao tác không đồng bộ.
- Xác minh kết quả.
- Tính đến hiệu suất.
| Nên ✅ | Không nên ❌ |
|---|---|
| Sử dụng lối tắt do API điều khiển. Tìm hiểu thêm. | Sử dụng các hoạt động tương tác trên giao diện người dùng cho mọi bước, bao gồm cả trình nối beforeEach. |
| Sử dụng quy trình dọn dẹp trước mỗi lần kiểm thử. Hãy chú ý hơn đến việc tách biệt kiểm thử so với kiểm thử đơn vị và kiểm thử tích hợp vì có nhiều nguy cơ xảy ra tác dụng phụ hơn. | Quên dọn dẹp sau mỗi lần kiểm thử. Nếu bạn không dọn dẹp trạng thái, dữ liệu hoặc hiệu ứng phụ còn lại, thì chúng sẽ ảnh hưởng đến các kiểm thử khác được thực thi sau này. |
| Xem xét kiểm thử toàn diện là kiểm thử hệ thống. Điều này có nghĩa là bạn cần kiểm thử toàn bộ ngăn xếp ứng dụng. | Kiểm thử từng đơn vị riêng biệt – đó là mục đích của kiểm thử đơn vị. |
| Sử dụng ít hoặc không sử dụng tính năng mô phỏng trong kiểm thử. Hãy cân nhắc kỹ nếu bạn muốn mô phỏng các phần phụ thuộc bên ngoài. | Phụ thuộc nhiều vào mô phỏng. |
| Cân nhắc hiệu suất và khối lượng công việc, chẳng hạn như không kiểm thử quá nhiều tình huống lớn trong cùng một kiểm thử. | Bao gồm các quy trình công việc lớn mà không cần sử dụng lối tắt. |