Khi một hàm beforeEach duy nhất làm tê liệt hệ thống CI suốt 36 giờ: Bài học đắt giá về kiểm thử tự động

Bài viết được dịch và tổng hợp từ tin tức gốc. Bạn có thể đọc bài viết gốc bằng tiếng Anh tại đây.

Điểm tin nhanh:

• Một hàm beforeEach bị cấu hình sai đã vô tình kích hoạt các tác vụ không mong muốn trong toàn bộ bộ kiểm thử.
• Hậu quả là hệ thống CI bị treo, gây gián đoạn quy trình phát triển phần mềm suốt 36 giờ.
• Bài học về việc cô lập môi trường kiểm thử và tầm quan trọng của việc kiểm soát các tác vụ chạy ngầm.

Trong thế giới phát triển phần mềm, chúng ta thường nghe về những lỗi nghiêm trọng do mã nguồn production gây ra, nhưng ít ai ngờ rằng một dòng lệnh nhỏ bé trong môi trường kiểm thử lại có thể trở thành "sát thủ" thầm lặng. Khi hệ thống CI/CD của bạn đột ngột ngừng hoạt động và kéo dài suốt 36 giờ, đó không chỉ là vấn đề kỹ thuật, mà là một bài học đắt giá về sự chủ quan trong việc thiết lập các hook kiểm thử.

Sự cố bắt đầu từ đâu?

Trong các framework kiểm thử như Jest hay Mocha, beforeEach là một công cụ mạnh mẽ để thiết lập trạng thái ban đầu cho mỗi bài kiểm thử. Tuy nhiên, nếu không được kiểm soát chặt chẽ, nó có thể trở thành con dao hai lưỡi. Trong trường hợp này, một hàm beforeEach đã được cấu hình để thực hiện các tác vụ khởi tạo tài nguyên mà không có cơ chế dọn dẹp hoặc giới hạn phạm vi, dẫn đến việc tích tụ tài nguyên quá mức.

Việc tối ưu hóa quy trình kiểm thử là cần thiết, nhưng như đã phân tích trong bài viết Khi tối ưu hóa quy trình trở thành cái gai trong mắt đồng nghiệp: Bài học về văn hóa kỹ thuật, đôi khi sự tinh chỉnh quá mức lại dẫn đến những hệ lụy khó lường.

Phân tích tác động của sự cố

Sự cố này không chỉ dừng lại ở việc làm chậm các bài kiểm thử mà còn khiến toàn bộ pipeline bị treo do cạn kiệt tài nguyên hệ thống. Dưới đây là bảng so sánh trạng thái hệ thống trước và sau khi xảy ra sự cố:

Khi đối mặt với các lỗi hệ thống phức tạp, việc tin tưởng vào các thông báo lỗi đôi khi là sai lầm, hãy tham khảo thêm bài viết về Xây dựng công cụ xác thực trạng thái công việc: Khi lập trình viên không còn tin vào những thông báo giả để có cái nhìn khách quan hơn.

Tại sao CI lại sụp đổ?

Vấn đề cốt lõi nằm ở việc hàm beforeEach thực hiện các yêu cầu mạng (network requests) không được mock một cách đúng đắn. Mỗi khi một bài test chạy, nó lại tạo ra một kết nối mới, và vì không được đóng lại hoặc hủy bỏ, các kết nối này chồng chất lên nhau. Điều này tương tự như việc ghim phiên bản không đúng cách, gây gián đoạn quy trình cập nhật, giống như những gì đã được cảnh báo trong bài Tại sao việc ghim phiên bản MCP lại đang âm thầm làm gián đoạn quy trình cập nhật phần mềm của bạn?.

Mẹo hay: Luôn luôn sử dụng các thư viện mocking như MSW (Mock Service Worker) để đảm bảo các yêu cầu mạng trong môi trường test được cô lập hoàn toàn.

Đánh giá & Lời khuyên Thực tiễn

Từ góc độ của một kỹ sư cấp cao, sự cố này là một lời nhắc nhở về việc quản lý tài nguyên trong môi trường test.

• Ưu điểm: beforeEach giúp code test sạch sẽ và dễ đọc.
• Nhược điểm: Dễ gây ra các side-effect nếu không được quản lý tốt.
• Phạm vi ứng dụng: Chỉ nên sử dụng cho các thiết lập trạng thái đơn giản (ví dụ: reset biến, clear mock).

Lưu ý: Nếu bạn thấy hệ thống CI của mình bắt đầu chạy chậm dần theo thời gian, hãy kiểm tra ngay các hàm setup/teardown. Đừng để tình trạng này kéo dài dẫn đến việc phải đối mặt với những thảm họa lớn hơn như khi 236 bài kiểm thử đều vượt qua nhưng hệ thống vẫn sụp đổ.

Câu hỏi thường gặp (FAQ)

Tại sao beforeEach lại nguy hiểm?

Nó chạy trước mỗi bài test, nếu hàm này thực hiện các tác vụ nặng hoặc không dọn dẹp tài nguyên, nó sẽ nhân bản lỗi đó lên số lượng bài test bạn có.

Làm sao để debug lỗi CI bị treo?

Hãy bắt đầu bằng việc chạy test trên máy local với chế độ debug, kiểm tra logs của CI và sử dụng các công cụ giám sát tài nguyên.

Có nên dùng afterEach không?

Chắc chắn rồi, afterEach là nơi tốt nhất để dọn dẹp các tài nguyên như kết nối database, mock timers, hoặc các event listeners.

Kết luận

Sự cố 36 giờ này là một bài học đắt giá về việc không bao giờ được chủ quan với những phần cấu hình tưởng chừng như đơn giản nhất. Hãy luôn đảm bảo quy trình kiểm thử của bạn được cô lập và có cơ chế dọn dẹp tài nguyên hiệu quả. Nếu bạn đang gặp khó khăn trong việc tối ưu hóa quy trình, hãy theo dõi hi_dev để cập nhật những kiến thức mới nhất về DevOps và kỹ thuật phần mềm.