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