Nơi chạy thử nghiệm

Thông thường, kiểm thử tự động có thể được chạy bằng cách chạy tập lệnh theo cách thủ công hoặc sử dụng một trình trợ giúp từ mộ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 phải chạy tập lệnh theo cách thủ công. Bạn có thể cung cấp ý kiến phản hồi và chia sẻ nhiều cách để tiến hành kiểm thử độ tin cậy ở các điểm khác nhau 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ó một tệp cấu hình (tệp package.json của chúng), tức là bằng npm, pnpm, Bun hoặc các thiết bị tương tự. Tệp cấu hình này chứa phần phụ thuộc của dự án và thông tin khác cũng như tập lệnh trợ giúp. Các tập lệnh trợ giúp có thể bao gồm cách tạo, chạy hoặc kiểm thử dự án.

Bên trong package.json, bạn cần thêm tập lệnh có tên test. Tập lệnh này mô tả cách chạy bài 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ụ, "kiểm thử" tập lệnh có ý nghĩa đặc biệt. Tập lệnh này có thể chỉ trỏ đến một tệp gửi ra trường hợp ngoại lệ: chẳng hạn như node tests.js, nhưng bạn nên sử dụng nó để trỏ đến một trình chạy kiểm thử uy tín.

Nếu bạn đang sử dụng Vitest làm trình chạy kiểm thử, Tệp package.json sẽ có dạng như sau:

{
  "name": "example-project",
  "scripts": {
    "start": "node server.js",
    "test": "vitest --run"
  }
}

Khi chạy npm test bằng tệp này, bạn sẽ chạy bộ kiểm thử mặc định của Vitest một lần. Trong Vitest, theo mặc định, 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 biến đó. Tùy thuộc vào trình chạy kiểm thử đã chọn, lệnh có thể hơi khác.

Chúng tôi đã chọn sử dụng Vitest, một khung kiểm thử ngày càng phổ biến, cho ví dụ trong suốt khoá học này. Bạn có thể đọc thêm về quyết định này trong Vitest với tư cách trình chạy kiểm thử. Tuy nhiên, điều quan trọng cần nhớ là khung kiểm thử và trình chạy – ngay cả khi đa ngôn ngữ—thường có tiếng Anh giống nhau.

Lệnh gọi kiểm thử theo cách thủ công

Kích hoạt theo cách thủ công các thử nghiệm tự động (chẳng hạn như sử dụng npm test trong ví dụ trước) có thể hữu ích 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 cách hoạt động của tính năng—điều này đề cập đến khái niệm phát triển dựa trên thử nghiệm (TDD).

Trình chạy kiểm thử thường 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 chương trình kiểm thử và có thể có cả chế độ theo dõi (có thể là chế độ theo dõi) chạy lại chương trình kiểm thử khi bạn lưu chúng. Đây là tất cả các lựa chọn hữu ích trong khi phát triển một tính năng mới và chúng được thiết kế nhằm giúp bạn dễ dàng viết một tính năng mới, các bài kiểm thử của tính năng đó hoặc cả hai, nhờ phản hồi nhanh chóng. 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 lượt kiểm thử tìm thấy. T4 bạn nên để mở này trong một cửa sổ khác trong khi viết mã kiểm thử để có thể nhận được phản hồi nhanh chóng về các bài kiểm thử khi bạn phát triển chúng.

Một số trình chạy cũng cho phép bạn đánh dấu kiểm thử là only trong mã. Nếu mã của bạn bao gồm 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 quá trình phát triển kiểm thử diễn ra nhanh chóng và dễ dàng hơn. Ngay cả khi tất cả thử nghiệm hoàn tất một cách nhanh chóng, việc sử dụng only có thể giảm chi phí vận hành và loại bỏ gây sao lãng 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 toàn bộ bộ kiểm thử của cơ sở mã thường xuyên. Điều này đặc biệt hữu ích nếu các thử nghiệm của bạn có quy mô nhỏ và hoàn tất nhanh chóng (không vài giây cho tất cả các thử nghiệm) để bạn có thể đảm bảo mọi thứ đang hoạt động trước khi bạn 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 chính xác khi mã sẽ được hợp nhất lại vào nhánh main. Nếu bạn mới thử nghiệm, nhưng đã đóng góp vào các dự án nguồn mở trong quá khứ. Bạn có thể nhận thấy của quy trình yêu cầu lấy dữ liệu (PR) xác nhận rằng tất cả các kiểm thử của dự án tức là đóng góp mới thú vị của bạn không ảnh hưởng tiêu cực đến dự án hiện có.

Nếu bạn chạy chương trình kiểm thử cục bộ, thì kho lưu trữ trực tuyến của dự án (ví dụ: GitHub hoặc một dịch vụ lưu trữ mã khác) sẽ không biết rằng các kiểm thử của bạn đã thành công, Vì vậy, việc chạy thử nghiệm dưới dạng nhiệm vụ trước khi gửi sẽ giúp tất cả cộng tác viên hiểu rõ rằng mọi thứ đều hoạt động tốt.

Ví dụ: GitHub gọi những tính năng này là "kiểm tra trạng thái" mà bạn có thể thêm qua GitHub Actions. Hành động trên GitHub là về cơ bản là một loại thử nghiệm: mỗi bước phải thành công (không được thất bại hoặc đưa ra một Error) để truyền hành động. Bạn có thể áp dụng Thao tác cho tất cả các PR cho một dự án, và dự án có thể yêu cầu phải chuyển Actions (Thao tác) trước khi bạn đóng góp mã. thuộc tính GitHub hành động Node.js mặc định chạy npm test theo một trong các bước của nó.

Đây là phương pháp kiểm thử nhằm đảm bảo cơ sở mã của bạn luôn có trạng thái "xanh" bằng cách không chấp nhận mã không chạy thử nghiệm thành công.

Chạy hoạt động kiểm thử trong tính năng Tích hợp liên tục

Sau khi PR xanh của bạn được chấp nhận, hầu hết các cơ sở mã sẽ chạy kiểm thử lại dựa trên nhánh main của dự án của bạn, thay vì PR trước đó. Điều này có thể xảy ra ngay lập tức hoặc thường xuyên (ví dụ: hằng giờ hoặc hằng đêm). Các kết quả thường xuất hiện trong trang tổng quan Tích hợp liên tục (CI) cho thấy trạng thái 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ỏ — thử nghiệm đã vượt qua trong quá trình xem xét, do đó, chúng sẽ vượt qua khi có thay đổi. Tuy nhiên, không phải lúc nào cũng đúng! Thử nghiệm của bạn có thể đột ngột thất bại, ngay cả sau khi thành công cho ra kết quả xanh. Một số lý do 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à tình huống tương tranh, và chúng tác động lẫn nhau theo những cách tinh tế và chưa được kiểm chứng.
• Các thử nghiệm của bạn không tái tạo được hoặc thử nghiệm "không ổn định" mã – cả hai đều có thể truyền và không thành công mà không 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 proxy, hãy tưởng tượng thử nghiệm nếu Math.random() > 0.05—tỷ lệ này sẽ ngẫu nhiên không thành công là 5% thời gian.
• Một số thử nghiệm quá tốn kém hoặc tốn kém nên không thể chạy trên mọi hoạt động quan hệ công chúng, chẳng hạn như chạy toàn bộ thử nghiệm (bạn có thể tìm hiểu thêm về nội dung này trong loại thử nghiệm tự động), và chúng có thể hỏng 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 cần nhận ra rằng kiểm thử và phát triển phần mềm nói chung, sẽ không bao giờ là một khoa học.

Một đoạn tạm thời khi khôi phục

Khi quá trình kiểm thử diễn ra trong quá trình tích hợp liên tục, kể cả khi quy trình kiểm thử chạy trong quá trình kiểm tra trạng thái, có thể bản dựng có "màu đỏ" hoặc một trạng thái khác có nghĩa là kiểm thử 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 thử nghiệm hoặc các bài kiểm thử không ổn định.

Đối với các dự án nhỏ, bản năng của bạn có thể coi đó là một cuộc khủng hoảng! Dừng mọi thứ, khôi phục hoặc huỷ bỏ thay đổi vi phạm và quay lại phiên bản đã biết trạng thái tố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à thử nghiệm (và phần mềm nói chung!) là mục đích cuối cùng chứ không phải là một mục tiêu . Mục tiêu của bạn có lẽ là viết phần mềm, không phải là làm cho tất cả các kiểm thử thành công. Thay vào đó, bạn có thể tiếp tục bằng cách tiếp tục thay đổi có thể gây lỗi bằng một thay đổi khác để khắc phục các thử nghiệm không thành công.

Mặt khác, bạn có thể đã thấy hoặc làm việc về những dự án lớn đã tồn tại ở trạng thái bị hỏng vĩnh viễn. Hay tệ hơn, một dự án lớn có kiểm thử không ổn định thường xuyên nghỉ ngơi đủ để gây mệt mỏi với chuông báo trong các nhà phát triển. Đây thường là một vấn đề hiện hữu để các nhà lãnh đạo giải quyết: thử nghiệm thậm chí có thể bị tắt vì chúng được coi là "ngăn chặn phát triển".

Không có cách khắc phục nhanh nào cho vấn đề này, nhưng có thể giúp bạn tự tin hơn khi viết kiểm thử (nâng cao kỹ năng) và giảm phạm vi kiểm tra (đơn giản hoá) để lỗi có thể dễ dàng xác định hơn. Số lượng kiểm thử thành phần tăng lên hoặc kiểm thử tích hợp (tìm hiểu thêm về các loại trong Các loại kiểm thử tự động thử nghiệm) có thể giúp tăng độ tin cậy hơn một thử nghiệm toàn diện quy mô lớn, khó duy trì và cố gắng thực hiện làm mọi thứ cùng một lúc.

Tài nguyên

• Lợi ích của việc xây dựng vào ban đêm là gì

Kiểm tra kiến thức