Computer >> Máy Tính >  >> Lập trình >> Ruby

Cách sử dụng viên ngọc VCR để cải thiện bộ thử nghiệm của bạn

Nếu ứng dụng Ruby của bạn sử dụng bất kỳ loại API bên ngoài nào thì có thể bạn đã phải đối mặt với vấn đề kiểm tra chậm và giới hạn tốc độ API .

Giải pháp là gì?

Bạn có thể khai báo thủ công các phương thức HTTP từ thư viện khách hàng của mình và trả về một số phản hồi được xác định trước.

Nhưng đó là rất nhiều công việc và mã xấu!

Giải pháp tốt hơn là sử dụng sự kết hợp mạnh mẽ của các viên ngọc như Webmock + VCR .

WebMock chặn các yêu cầu HTTP từ các thư viện HTTP phổ biến, như:

  • net / http
  • Faraday
  • RestClient
  • … nhiều hơn nữa!

Chỉ điều này là hữu ích, nhưng bạn vẫn phải cung cấp dữ liệu phản hồi.

Đây là nơi VCR xuất hiện…

VCR hoạt động kết hợp với WebMock để ghi lại các phản hồi HTTP do mã của bạn thực hiện .

Những bản ghi âm này được gọi là “băng cassette”.

Khi bạn chạy thử nghiệm của mình :

VCR sẽ tải các tệp băng cassette và trả lại các phản hồi đã ghi. Bạn sẽ nhận được phản hồi nhanh hơn vì bạn không phải hỏi API thực.

Hãy xem một số ví dụ về mã!

Ví dụ về mã VCR

Đối với ví dụ này, chúng tôi sẽ sử dụng RSpec vì nó tích hợp tốt hơn với VCR như bạn sẽ thấy trong phần tiếp theo.

Đây là mã chúng tôi muốn kiểm tra :

require "faraday"
require "json"

class Github
  def self.user(name)
    url  = "https://api.github.com/users/#{name}"
    data = Faraday.get(url).body

    JSON.parse(data, symbolize_names: true)
  end
end

Nó yêu cầu API Github để lấy thông tin về một người dùng cụ thể. Khá đơn giản nhưng nó sẽ giúp chúng ta tìm hiểu về cách hoạt động của VCR.

Kiểm tra mã này có thể trông như thế này :

require "rspec/autorun"

require_relative "github_api_example"

describe Github do
  let(:user_response) { Github.user("ruby") }

  it "can fetch & parse user data" do
    expect(user_response).to be_kind_of(Hash)

    expect(user_response).to have_key(:id)
    expect(user_response).to have_key(:type)
  end
end

Thao tác này sẽ truy cập API &pass thực, nhưng mất khoảng nửa giây để hoàn thành.

Nửa giây cho MỘT bài kiểm tra!

Có thể không nhiều, nhưng hãy tưởng tượng rằng bạn có hàng trăm bài kiểm tra, tức là 50 giây để chạy tất cả chúng.

Đã đến lúc khắc phục điều đó…

Hãy giới thiệu VCR bằng cách thêm đoạn mã này :

require "vcr"

VCR.configure do |c|
  c.cassette_library_dir = "spec/vcr"
  c.hook_into :webmock
end

Bạn có thể thêm mã này trong test_helper tệp, vì vậy nó có sẵn cho tất cả các thử nghiệm của bạn

Với configure này chặn bạn đang cho VCR biết nơi lưu các tệp cassette và bật tích hợp WebMock.

Nếu bạn đang sử dụng Faraday hoặc Excon, thì VCR có thể kết nối trực tiếp với chúng.

Chỉ cần thay thế :webmock với :faraday hoặc :excon .

Tiếp theo :

Bạn phải cho VCR biết tên của các băng và mã nào sẽ chạy dưới các băng này.

Đây là cách thực hiện :

let(:user_response) do
  VCR.use_cassette("github/user") { Github.user("ruby") }
end

Khi bạn chạy các bài kiểm tra của mình, VCR sẽ tạo một tệp dưới cassette_library_dir , trong trường hợp này, tên tệp sẽ là spec/vcr/github/user.yaml , nếu bạn đang theo dõi, bạn có thể muốn xem nó.

Nếu tôi chạy các bài kiểm tra bây giờ, nó sẽ nhanh hơn rất nhiều .

Thực tế…

Chỉ mất 0,01 giây để hoàn thành!

“Một yêu cầu HTTP đã được thực hiện mà VCR không biết cách xử lý”

Nếu bạn gặp phải thông báo lỗi này, điều đó có nghĩa là một trong hai điều:

1.Bạn đang cố thực hiện cuộc gọi HTTP với VCR được bật nhưng bên ngoài VCR.use_cassette khối.

Giải pháp :Theo mặc định VCR + WebMock chặn tất cả các yêu cầu HTTP. Bạn có thể thay đổi điều này bằng các tùy chọn cấu hình, thêm khối VCR bị thiếu hoặc sử dụng siêu dữ liệu RSpec (phần tiếp theo).

2.Bạn đang cố đưa ra một yêu cầu khác và sử dụng một băng cassette không khớp với URL này. Ví dụ:nếu bạn yêu cầu trong các bài kiểm tra của mình /users/ruby , băng được tạo riêng cho URL này, nếu bạn thay đổi kiểm tra thành /users/apple thì bạn sẽ thấy lỗi này vì băng cát xét dành cho một URL khác.

Giải pháp :Sử dụng các băng khác nhau cho các URL khác nhau, bật new_episodes chế độ ghi (vcr: { record: :new_episodes } ) hoặc xóa băng cũ sau khi bạn cập nhật URL yêu cầu.

Cách sử dụng siêu dữ liệu RSpec

VCR.use_cassette là một cách tốt để sử dụng gem này.

Nhưng…

Bạn cũng có thể cho phép VCR tạo băng cát xét tự động cho bạn.

Làm thế nào?

Thêm cái này vào bên trong VCR.configure khối:

c.configure_rspec_metadata!

Bây giờ bạn có thể bật VCR cho một bài kiểm tra cụ thể (it khối), hoặc cho một nhóm thử nghiệm (describe ).

Như thế này :

describe Github, :vcr do
  # ...
end

Thao tác này sẽ tạo các tệp băng cassette được đặt tên theo mô tả thử nghiệm :

spec/vcr/
└── Github
    ├── can_parse_user_data.yml
    └── can_test_vcr.yml

Lưu ý rằng điều này sẽ tạo ra một băng cát xét cho mỗi lần kiểm tra…

Ngay cả khi hai bài kiểm tra đưa ra cùng một yêu cầu và sử dụng cùng một dữ liệu. VCR sẽ tạo các băng cassette riêng cho chúng.

Các tùy chọn và mẹo VCR hữu ích

Nếu bạn gặp sự cố với băng cát-xét của mình hoặc nếu bạn muốn có phiên bản dữ liệu mới, thì bạn có thể xóa tệp cát-xét .

VCR sẽ ghi lại các phản hồi API mới và có thể giải quyết vấn đề của bạn.

Nhưng nếu không thì sao?

Bạn có thể bật chế độ gỡ lỗi trong VCR.configure :

VCR.configure do |c|
  # ...
  c.debug_logger = $stderr
end

Điều này có thể tạo ra nhiều đầu ra, vì vậy hãy giới hạn các thử nghiệm của bạn chỉ với những người bạn quan tâm.

Tiếp theo :

Giả sử có các khóa API hoặc dữ liệu nhạy cảm khác như một phần của phản hồi API…

Bạn có thể muốn lọc dữ liệu đó khỏi bản ghi.

Đây là cách thực hiện :

VCR.configure do |c|
  # ...
  c.define_cassette_placeholder("<API_KEY>", ENV["API_KEY"])
end

Tóm tắt

Bạn đã học cách sử dụng đá quý WebMock &VCR để bạn có thể viết thử nghiệm cho các ứng dụng Ruby của mình mà không cần phải đợi phản hồi API bên ngoài!

Cách sử dụng viên ngọc VCR để cải thiện bộ thử nghiệm của bạn

Nếu bạn thích điều này, đừng quên chia sẻ bài viết này để nhiều người cùng thưởng thức.

Cảm ơn vì đã đọc 🙂