Thông thường, bạn có thể chạy kiểm thử tự động bằng cách chạy tập lệnh theo cách thủ công hoặc sử dụng trình trợ giúp từ khung kiểm thử (thường được gọi là trình chạy kiểm thử) để tìm và chạy kiểm thử. Tuy nhiên, không phải lúc nào bạn cũng muốn chạy tập lệnh theo cách thủ công. Có một số cách chạy kiểm thử có thể đưa ra ý kiến phản hồi và mức độ tin cậy tại nhiều thời điểm trong vòng đời phát triển.
Tập lệnh điều kiện tiên quyết
Các dự án web thường có tệp cấu hình (tệp package.json của các dự án đó) được thiết lập theo npm, pnpm, Bun hoặc các thành phần tương tự. Tệp cấu hình này chứa các phần phụ thuộc và các thông tin khác của dự án, cũng như tập lệnh trợ giúp. Các tập lệnh trợ giúp này có thể bao gồm cách tạo, chạy hoặc kiểm thử dự án của bạn.
Bên trong package.json, bạn cần thêm một tập lệnh có tên là test để mô tả cách chạy kiểm thử. Điều này rất quan trọng vì khi sử dụng npm hoặc một công cụ tương tự, tập lệnh"kiểm thử" có ý nghĩa đặc biệt.
Tập lệnh này có thể chỉ trỏ đến một tệp trả về một ngoại lệ (chẳng hạn như node tests.js), nhưng bạn nên sử dụng tập lệnh này để trỏ đến một trình chạy kiểm thử ổn định.
Nếu bạn đang sử dụng Vitest làm trình kiểm thử, tệp package.json sẽ có dạng như sau:
{
"name": "example-project",
"scripts": {
"start": "node server.js",
"test": "vitest --run"
}
}
Việc chạy npm test với tệp này sẽ chạy nhóm bài kiểm thử mặc định của Vitest một lần. Trong Vitest, cách mặc định là tìm tất cả các tệp kết thúc bằng ".test.js" hoặc tương tự và chạy các tệp đó. Tuỳ thuộc vào trình chạy kiểm thử mà bạn chọn, lệnh có thể hơi khác nhau.
Chúng tôi đã chọn sử dụng Vitest, một khung kiểm thử ngày càng phổ biến, làm ví dụ trong suốt khoá học này. Bạn có thể đọc thêm về quyết định này trong phần Vitest as a test runner (Kiểm thử dưới dạng trình chạy kiểm thử). Tuy nhiên, điều quan trọng cần nhớ là các khung kiểm thử và trình chạy (ngay cả trên nhiều ngôn ngữ) thường có cùng một ngôn ngữ.
Lệnh gọi kiểm thử theo cách thủ công
Việc kích hoạt các bài kiểm thử tự động theo cách thủ công (chẳng hạn như sử dụng npm test trong ví dụ trước) có thể thiết thực trong khi bạn đang tích cực xử lý cơ sở mã.
Việc viết mã kiểm thử cho một tính năng trong khi phát triển tính năng đó có thể giúp bạn nắm được cách hoạt động của tính năng đó. Việc viết mã kiểm thử này đề cập đến khái niệm phát triển dựa trên kiểm thử (TDD).
Trình chạy kiểm thử thường sẽ có một lệnh ngắn mà bạn có thể gọi để chạy một số hoặc tất cả các kiểm thử và có thể có chế độ theo dõi chạy lại kiểm thử khi bạn lưu các kiểm thử đó. Đây đều là những tuỳ chọn hữu ích trong khi phát triển tính năng mới và được thiết kế để giúp bạn dễ dàng viết một tính năng mới, các bài kiểm thử hoặc cả hai, tất cả đều bằng phản hồi nhanh. Ví dụ: Vitest hoạt động ở chế độ theo dõi theo mặc định: lệnh vitest sẽ theo dõi các thay đổi và chạy lại mọi kiểm thử được tìm thấy. Bạn nên mở cửa sổ này trong một cửa sổ khác trong khi viết chương trình kiểm thử để có thể nhanh chóng nhận được ý kiến phản hồi nhanh chóng về các chương trình kiểm thử của mình trong quá trình phát triển các chương trình kiểm thử đó.
Một số trình chạy cũng cho phép bạn đánh dấu các bài kiểm thử là only trong mã. Nếu mã của bạn bao gồm các kiểm thử only, thì chỉ những kiểm thử này mới kích hoạt khi bạn chạy kiểm thử, giúp việc phát triển kiểm thử nhanh chóng và dễ dàng khắc phục sự cố hơn. Ngay cả khi tất cả chương trình kiểm thử của bạn hoàn tất nhanh chóng, việc sử dụng only có thể giúp bạn giảm mức hao tổn tài nguyên và loại bỏ sự phân tâm khi chạy các chương trình kiểm thử không liên quan đến tính năng hoặc chương trình kiểm thử bạn đang thực hiện.
Đối với các dự án nhỏ, đặc biệt là các dự án chỉ có một nhà phát triển, bạn cũng có thể muốn xây dựng thói quen chạy thường xuyên toàn bộ bộ kiểm thử của cơ sở mã. Điều này đặc biệt hữu ích nếu các kiểm thử của bạn có quy mô nhỏ và hoàn thành nhanh chóng (không quá vài giây cho tất cả các kiểm thử) để bạn có thể đảm bảo mọi thứ đang hoạt động trước khi tiếp tục.
Chạy thử nghiệm trong quá trình gửi trước hoặc xem xét
Nhiều dự án chọn xác nhận rằng cơ sở mã đang hoạt động đúng cách khi mã được hợp nhất trở lại vào nhánh main của nó. Nếu bạn mới tham gia kiểm thử nhưng đã đóng góp cho các dự án nguồn mở trước đây, thì bạn có thể nhận thấy một phần của quy trình yêu cầu lấy dữ liệu (PR) xác nhận rằng mọi bài kiểm thử của dự án đều đạt, nghĩa là nội dung đóng góp mới thú vị của bạn chưa ảnh hưởng tiêu cực đến dự án hiện tại.
Nếu bạn chạy kiểm thử cục bộ, kho lưu trữ trực tuyến của dự án (ví dụ: GitHub hoặc dịch vụ lưu trữ mã khác) sẽ không biết rằng kiểm thử của bạn đang thành công, vì vậy, việc chạy kiểm thử dưới dạng tác vụ gửi trước sẽ giúp tất cả những người đóng góp biết rõ rằng mọi thứ đều đang hoạt động.
Ví dụ: GitHub gọi những hoạt động này là "kiểm tra trạng thái" mà bạn có thể thêm thông qua GitHub Actions. Về cơ bản, Hành động trên GitHub là một loại kiểm thử: mỗi bước phải thành công (không thất bại hoặc phải gửi một Error) để hành động đó vượt qua. Bạn có thể áp dụng Hành động cho tất cả các PR của một dự án và dự án có thể yêu cầu Hành động đó phải chuyển trước khi bạn đóng góp mã. Thao tác Node.js mặc định của GitHub chạy npm test dưới dạng một trong các bước của thao tác này.
Phương pháp kiểm thử này cố gắng đảm bảo cơ sở mã của bạn luôn có màu "xanh" bằng cách không chấp nhận đoạn mã không chạy thành công các hoạt động kiểm thử.
Chạy kiểm thử trong tính năng Tích hợp liên tục
Sau khi PR màu xanh lục của bạn được chấp nhận, hầu hết các cơ sở mã sẽ chạy kiểm thử một lần nữa dựa trên nhánh main của dự án, thay vì PR trước đó. Quá trình này có thể xảy ra ngay lập tức hoặc theo định kỳ (ví dụ: hằng giờ hoặc hằng đêm). Những kết quả này thường xuất hiện trong trang tổng quan của tính năng Tích hợp liên tục (CI) cho biết tình trạng tổng thể của dự án.
Bước CI này có vẻ không cần thiết, đặc biệt là đối với các dự án có cơ sở mã nhỏ – các bài kiểm thử đã được vượt qua trong quá trình xem xét, vì vậy, chúng sẽ đạt sau khi có thay đổi. Tuy nhiên, điều này không phải lúc nào cũng đúng! Hoạt động kiểm thử của bạn có thể thất bại đột ngột, ngay cả sau khi tạo thành công kết quả màu xanh lục. Một số lý do dẫn đến điều này bao gồm:
- Một số thay đổi được chấp nhận "cùng một lúc", đôi khi được gọi là điều kiện tranh đấu, và chúng ảnh hưởng lẫn nhau theo những cách tinh vi và chưa được thử nghiệm.
- Các bài kiểm thử của bạn không thể tái tạo hoặc kiểm thử mã "không ổn định" – cả hai đều có thể đạt và không thành công mà không cần thay đổi mã.
- Điều này có thể xảy ra nếu bạn phụ thuộc vào các hệ thống bên ngoài cơ sở mã của mình. Đối với một proxy, hãy tưởng tượng việc kiểm thử nếu
Math.random() > 0.05– tỷ lệ lỗi ngẫu nhiên sẽ là 5%.
- Điều này có thể xảy ra nếu bạn phụ thuộc vào các hệ thống bên ngoài cơ sở mã của mình. Đối với một proxy, hãy tưởng tượng việc kiểm thử nếu
- Một số chương trình kiểm thử quá tốn kém hoặc tốn kém khi chạy trên mọi hoạt động PR, chẳng hạn như kiểm thử từ đầu đến cuối (xem thêm về loại kiểm thử tự động) và có thể gặp lỗi theo thời gian mà không cần phải luôn cảnh báo.
Không có vấn đề nào trong số này là không thể khắc phục, nhưng bạn nên nhận ra rằng hoạt động kiểm thử và phát triển phần mềm nói chung không bao giờ là một khoa học chính xác.
Đoạn kết thúc khi hồi tưởng trở lại
Khi các chương trình kiểm thử chạy trong quá trình tích hợp liên tục và ngay cả khi các chương trình kiểm thử đang chạy trong quá trình kiểm tra trạng thái, có thể bản dựng sẽ ở trạng thái "đỏ" hoặc một trạng thái khác có nghĩa là các chương trình kiểm thử sẽ không thành công. Như đã đề cập trước đó, điều này có thể xảy ra vì một số lý do, bao gồm cả điều kiện tranh đấu khi gửi kiểm thử hoặc kiểm thử không ổn định.
Đối với những dự án nhỏ, bạn có khả năng coi đó là một khủng hoảng! Dừng mọi thứ, khôi phục hoặc hoàn nguyên thay đổi vi phạm và quay lại trạng thái tốt đã biết. Đây có thể là một phương pháp hợp lệ, nhưng điều quan trọng cần nhớ là kiểm thử (và phần mềm nói chung!) là phương tiện để đạt được mục đích chứ không phải là mục tiêu. Mục tiêu của bạn có thể là viết phần mềm, không phải để vượt qua mọi bài kiểm thử. Thay vào đó, bạn có thể tiến hành bằng cách tiếp tục thay đổi có thể gây lỗi với một thay đổi khác giúp sửa những lượt kiểm thử không thành công.
Mặt khác, bạn có thể đã thấy hoặc đã xử lý các dự án lớn tồn tại trong trạng thái hỏng vĩnh viễn. Hoặc tệ hơn, dự án lớn có một quy trình kiểm thử không ổn định, thường xuyên bị lỗi để gây ra hiện tượng mờ chuông báo ở nhà phát triển. Đây thường là một vấn đề tồn đọng mà các nhà lãnh đạo cần giải quyết: các chương trình kiểm thử này thậm chí có thể bị tắt vì chúng được coi là "đang cản trở quá trình phát triển".
Không có cách khắc phục nhanh cho vấn đề này, nhưng cách này có thể giúp bạn tự tin hơn khi viết chương trình kiểm thử (nâng cao kỹ năng) và giảm phạm vi kiểm thử (đơn giản hoá) để có thể xác định lỗi dễ dàng hơn. Số lượng kiểm thử thành phần hoặc kiểm thử tích hợp tăng lên (nhiều hơn về các loại trong Các loại kiểm thử tự động) có thể mang lại mức độ tin cậy cao hơn một kiểm thử toàn diện khổng lồ, khó duy trì và cố gắng làm mọi thứ cùng một lúc.
Tài nguyên
Kiểm tra kiến thức
Tên của tập lệnh đặc biệt mà npm và các chương trình tương tự tìm kiếm trong quá trình thử nghiệm là gì?