Giới thiệu

Khi một bài kiểm tra RSpec thất bại, điều đầu tiên mà chúng ta làm là cố gắng tìm ra lý do. Trong môi trường cục bộ, bạn có thể dừng quá trình với binding.b (sử dụng byebug, pry, v.v.) và điều tra trực tiếp trong bảng điều khiển. Nhưng đối với những bài kiểm tra không ổn định chỉ thất bại trên CI, việc gỡ lỗi chúng có thể trở nên khó khăn hơn rất nhiều.

Trong bài viết này, tôi sẽ chia sẻ một kỹ thuật nhỏ nhưng hữu ích: tùy chỉnh thông điệp lỗi trong RSpec. Thủ thuật này có thể giúp bạn ngay cả khi việc gỡ lỗi rất khó khăn trong môi trường CI.

Tham số thứ hai của expect(...).to matcher, message

Bạn có thể đã viết điều gì đó như thế này trước đây:

expect(actual).to eq(expected)

Điều ít được biết đến hơn là phương thức .to thực sự nhận một tham số thứ hai cho thông điệp lỗi:

expect(actual).to eq(expected), "Không khớp"

Nếu sự mong đợi thất bại, "Không khớp" sẽ được hiển thị. Thậm chí tốt hơn—bạn có thể truyền vào một khối thay vì một chuỗi đơn giản:

expect(actual).to eq(expected), -> { "Không khớp: actual=#{actual.inspect}" }

Khối này chỉ được đánh giá khi bộ so khớp thất bại, có nghĩa là bạn có thể nhúng thông tin trạng thái vào thông điệp lỗi—giống như ghi nhật ký tùy chỉnh.

Hữu ích cho việc gỡ lỗi các bài kiểm tra không ổn định trong CI

Các bài kiểm tra chỉ thất bại trên CI đặc biệt khó khăn vì việc tái tạo chúng cục bộ có thể là không thể. Đó là nơi mà kỹ thuật này tỏa sáng. Bạn có thể nhúng dữ liệu ngữ cảnh trực tiếp vào thông điệp lỗi:

expect(result).to eq("thành công"), -> {
  <<~MSG
    Kết quả không khớp.
    Giá trị thực tế: #{result.inspect}
    ID người dùng: #{user.id}
    Tham số yêu cầu: #{params.inspect}
  MSG
}

Với điều này, chính các nhật ký CI có thể chứa đủ thông tin để bạn tìm ra điều gì đã sai.

Cách hoạt động

Cơ chế này đến từ tham số thứ hai (message) của RSpec::Expectations::ExpectationHelper.handle_failure.

Bạn có thể xem mã liên quan tại đây:
Github RSpec Expectations

Thế còn .not_to và raise_error?

Kỹ thuật này hoạt động với .not_to và thậm chí expect { ... }.to raise_error. Bởi vì tất cả các bộ so khớp RSpec cuối cùng đều đi qua RSpec::Expectations::ExpectationHelper.handle_failure.

Thực hành tốt nhất

• Tùy chỉnh thông điệp lỗi: Đảm bảo rằng bạn luôn cung cấp thông điệp lỗi rõ ràng và hữu ích cho các bài kiểm tra của mình. Điều này giúp cho việc gỡ lỗi trở nên dễ dàng hơn.
• Nhúng thông tin ngữ cảnh: Trong các bài kiểm tra CI, hãy luôn cố gắng nhúng thông tin trạng thái vào thông điệp lỗi để dễ dàng theo dõi vấn đề.

Cạm bẫy thường gặp

• Quá tải thông tin: Tránh việc nhúng quá nhiều thông tin vào thông điệp lỗi, vì điều này có thể làm cho việc đọc nhật ký trở nên khó khăn hơn.
• Sử dụng không đúng cách: Đảm bảo rằng bạn sử dụng kỹ thuật này một cách hợp lý và chỉ khi thực sự cần thiết, tránh làm phức tạp hóa mã của bạn.

Mẹo hiệu suất

• Giảm thiểu thời gian gỡ lỗi: Sử dụng các công cụ gỡ lỗi như byebug hoặc pry để nhanh chóng tìm ra vấn đề trong mã của bạn.
• Tối ưu hóa các bài kiểm tra: Đảm bảo rằng các bài kiểm tra của bạn không chỉ chính xác mà còn nhanh chóng. Thời gian chạy các bài kiểm tra lâu có thể khiến bạn mất thời gian trong việc gỡ lỗi.

Kết luận

Bằng cách truyền tham số thứ hai hoặc một khối vào phương thức .to của RSpec, bạn có thể hoàn toàn tùy chỉnh thông điệp lỗi. Điều này không chỉ đơn thuần là thay đổi ngôn từ—đó cũng là một cách mạnh mẽ để để lại thông tin gỡ lỗi trong các nhật ký CI, đặc biệt đối với các bài kiểm tra không ổn định khó tái tạo cục bộ.

Lần tới khi bạn gặp một lỗi khó theo dõi, hãy thử kỹ thuật này—bạn có thể sẽ đến gần hơn với nguyên nhân gốc rễ của vấn đề.