2013-01-12 20 views
14

Chúng tôi muốn thiết lập công việc tự động (qua Jenkins) để cảnh báo nếu API của bên thứ ba ngừng hoạt động hoặc triển khai API không tương thích.Giám sát & kiểm tra API của bên thứ ba liên tục trên Rails

Tôi đang nói về để kiểm tra thực tế HTTP APIs và không phải là giả, nhưng khi chúng tôi đã có mô phỏng bằng cách sử dụng rspec, tôi không chắc chắn liệu chúng ta có nên nhân đôi nỗ lực bằng cách viết hai thử nghiệm độc lập.

Có ai có kinh nghiệm này trước đây không? (Tôi không giới hạn Ruby/Rspec nếu các công cụ khác có thể giúp)

Trả lời

3

Mocks được sử dụng để kiểm tra RIÊNG mã BẠN w/o chạm API thực. Và bạn muốn kiểm tra API thực.

Vì vậy, tôi nghĩ bạn phải viết một bộ kiểm tra trong RSpec, ví dụ: không phô trương kiểm tra API của bên thứ ba.
Bởi "không phô trương" Tôi có nghĩa là theo dõi hơn là bạn không đưa ra yêu cầu API "DELETE" ngẫu nhiên, hoặc sử dụng tất cả giới hạn API yêu cầu hàng ngày của bạn bằng một lần chạy bộ thử nghiệm duy nhất.

Không biết liệu các công cụ kiểm tra API được chỉ định có tồn tại hay không.
Đối với tôi, tôi đã sử dụng RSpec để kiểm tra các API/máy chủ từ xa của riêng mình thành công.

5

Bạn đã xem VCR chưa? Sử dụng nó, bạn có thể "ghi lại các tương tác HTTP của bộ thử nghiệm của bạn và phát lại chúng trong thời gian chạy thử nghiệm trong tương lai để kiểm tra nhanh, xác định, chính xác". Tôi đã sử dụng nó với RSpec khi kiểm tra phản hồi mong đợi từ các API bên ngoài và cho rằng nó tuyệt vời. Tôi muốn khuyến khích bạn kiểm tra các câu hỏi StackOverflow được gắn thẻ với nếu đó là điều bạn nghĩ có thể phù hợp với bạn.

Không chắc chắn về tích hợp Jenkins của nó, nhưng khi tôi đang sử dụng VCR, tôi đã tự động thực hiện một số tác vụ thường xuyên mà tôi cần để truy cập API với Whenever ("Cron jobs in Ruby"). Không thực sự liên tục, nhưng hơi tự động.

+1

Tôi đồng ý, VCR rất tuyệt cho việc này. Về cơ bản ghi lại một "hợp đồng" của các loại. Sau đó bạn có thể ghi lại và kiểm tra sự khác biệt. – irfn

4

Khi tôi còn trong tình huống này một vài tháng trước, tôi đã làm như sau:

  1. Mock API và viết bài kiểm tra đối với các dữ liệu chế giễu (bạn đã có)
  2. Viết thêm một bài kiểm tra mà được dữ liệu từ API thực và xác nhận rằng đó là (vẫn) trong cùng một biểu mẫu và chứa cùng một loại dữ liệu mà chúng tôi mong đợi

Tôi đã làm như vậy vì tôi không thể đoán/biết nội dung nào sẽ được cung cấp bởi API trực tiếp.

+0

Đó là những gì chúng tôi đã làm trong quá khứ. Bạn có thể lên lịch công việc Jenkins để kiểm tra xem bạn vẫn có thể tương tác với API của bên thứ ba hàng tuần hay hàng tuần và nó sẽ thông báo cho bạn về những thay đổi đối với API phụ thuộc. – bcarlso

+3

Một điều nữa ... Là một dịch vụ mà người khác phụ thuộc vào, chúng tôi đã đi xa đến mức khuyến khích điều này, và thiết lập một tài khoản e-mail, khi xây dựng của khách hàng không thành công do thay đổi API của chúng tôi, họ có thể thông báo cho chúng tôi thông qua thử nghiệm tự động của họ. Bằng cách này, chúng tôi biết khi nào chúng tôi đã tác động tiêu cực đến khách hàng của mình. – bcarlso

+0

Gần đây tôi đã tìm thấy đá quý Weary https://github.com/mwunsch/weary mà có vẻ là một cách tuyệt vời để "bọc" quyền truy cập của bạn vào bất kỳ API nào và viết các bài kiểm tra khá đơn giản (xem Gilt https://github.com/mwunsch/ gilt) – brutuscat

2

Có 2 điều tôi muốn làm với bộ thử nghiệm hiện tại để nó có thể được sử dụng trực tiếp, đầu tiên sử dụng khả năng dành cho các khối describeit để siêu dữ liệu (There's a good blog post on it here). Thứ hai sử dụng khả năng cho shared_contexts để có một khối.

Thứ nhất, đánh dấu các thông số kỹ thuật bạn muốn chạy với API thực bằng siêu dữ liệu. Ví dụ: bạn muốn biết những điều này có thể chạy thực, ví dụ:

describe "Hitting the API with a call", :can_be_real do 
    # … 
end 

Các thông số này sau đó có thể được chạy từ dòng lệnh using the tag option.

Điều thứ hai, là thay thế mocks bằng thực tế. Nó phụ thuộc vào cách bạn đã xác định các mocks, cho dù một before hoặc một let đã được sử dụng, và bao nhiêu bạn chế giễu. Như một ví dụ ngớ ngẩn, xem dưới đây:

require 'rspec' 

RSpec.configure do |c| 
    c.treat_symbols_as_metadata_keys_with_true_values = true 
end 

shared_context "all my mocks and stubs" do 
    let(:this) { false } 
end 

describe "a", :real do 
    include_context "all my mocks and stubs" do 
    let(:this) { true } if ENV["REAL_API_CALL"] == 'true' 
    before do 
     stub_const("URI", Class.new) unless ENV["REAL_API_CALL"] == 'true' 
    end 
    end 
    it "should be real when it's real" do 
    this.should == true 
    end 
    it "should escape things when it's real" do 
    URI.should respond_to :escape 
    end 
end 

Khi tập tin được chạy qua bin/rspec example.rb đầu ra là:

a 
    should be real when it's real (FAILED - 1) 
    should escape things when it's real (FAILED - 2) 

Failures: 

    1) a should be real when it's real 
    Failure/Error: this.should == true 
     expected: true 
      got: false (using ==) 
    # ./example.rb:19:in `block (2 levels) in <top (required)>' 

    2) a should escape things when it's real 
    Failure/Error: URI.should respond_to :escape 
     expected URI to respond to :escape 
    # ./example.rb:22:in `block (2 levels) in <top (required)>' 

Finished in 0.00349 seconds 
2 examples, 2 failures 

Khi chạy qua env REAL_API_CALL=true bin/rspec example.rb:

a 
    should be real when it's real 
    should escape things when it's real 

Finished in 0.00301 seconds 
2 examples, 0 failures 

Vì vậy, bạn thấy, bạn có thể thay đổi bối cảnh của các số kỹ thuật theo một số cách cho phép bạn kiểm soát mức độ bạn muốn từ dòng lệnh (và do đó, Jenkins). Bạn sẽ muốn đánh dấu các thông số với siêu dữ liệu khác, chẳng hạn như liệu có an toàn để chạy thực hay không, có thể mất một thời gian dài hay không…

Các vấn đề liên quan