Ciągłe monitorowanie i testowanie interfejsów API stron trzecich w Railsach

Question

Chcielibyśmy skonfigurować automatyczne zadania (za pośrednictwem Jenkins), aby ostrzec, czy interfejs API innej firmy nie działa lub wdrożyli niezgodne interfejsy API.

Mam zamiar przetestować na prawdziwym HTTP APIs, a nie na próbach, ale jak już mamy fałszywe napisane przy użyciu rspec, nie jestem pewien, czy powinniśmy powielić wysiłek pisząc dwa niezależne jądra.

Ktoś ma to już wcześniej? (nie jestem ograniczony do Ruby/Rspec jeśli inne narzędzia mogą pomóc)

Answer 1

Mocks służą do testowania własny kod w/o dotknięcie prawdziwego API. I chcesz przetestować prawdziwy interfejs API.

Więc myślę, że musisz napisać zestaw testów w RSpec na przykład dla dyskretny test z API innej firmy.
Przez "dyskretny" rozumiem ścieżkę, niż na przykład nie wydajesz przypadkowych żądań API "USUŃ" lub nie używaj wszystkich limitów API codziennych żądań za pomocą pojedynczego uruchomienia zestawu testów.

Nie wiem, czy istnieją określone narzędzia testowe interfejsu API.
Jeśli chodzi o mnie, użyłem RSpec do przetestowania własnych zdalnych interfejsów API/serwerów z powodzeniem.

Answer 2

Czy obejrzałeś VCR? Za jego pomocą można "rejestrować interakcje HTTP zestawu testowego i odtwarzać je podczas przyszłych testów w celu przeprowadzenia szybkich, deterministycznych i dokładnych testów". Używałem go z RSpec podczas testowania oczekiwanych odpowiedzi z zewnętrznych interfejsów API i uważam, że jest świetny. Zachęcam do zapoznania się z pytaniami związanymi z StackOverflow oznaczonymi vcr, jeśli uważasz, że to coś dla ciebie.

Nie jestem pewien swojej integracji z Jenkinsem, ale kiedy używałem magnetowidu, zautomatyzowałem niektóre regularne zadania, w których musiałem trafić interfejsy API pod Whenever ("zadania Cron w Ruby"). Niezupełnie ciągły, ale nieco zautomatyzowany.

Answer 3

Kiedy byłem w tej sytuacji kilka miesięcy temu zrobiłem następujący:

1. Mock API i pisać testy przeciwko szydzili danych (masz już tego)
2. napisać bardziej test, który dostaje dane z prawdziwego API i twierdzi, że jest (nadal) w tej samej formie i zawiera ten sam rodzaj danych, które oczekujemy:

Zrobiłem to w ten sposób, ponieważ nie byłem w stanie odgadnąć/wiedzieć, jakie treści będzie dostarczane przez API na żywo.

Answer 4

Jest 2 rzeczy, które chciałbym zrobić z istniejącym zestawem testowym, aby mógł być używany na żywo, pierwszy korzysta z możliwości blokowania describe i it do pobierania metadanych (There's a good blog post on it here). Drugi używa możliwości, aby shared_contexts wziął blok.

Po pierwsze, zaznacz specyfikacje, które chcesz uruchomić w stosunku do rzeczywistego API z metadanymi. Na przykład chcesz wiedzieć, że można je uruchamiać naprawdę, np.

Te specyfikacje można następnie uruchomić z wiersza poleceń using the tag option.

Drugą rzeczą jest zastąpienie makiety rzeczywistością. Zależy to od tego, jak zdefiniowałeś drwiny, czy użyto before lub let i ile wyśmiewałeś. Jak głupie przykład, patrz poniżej:

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 

Gdy plik jest uruchamiany poprzez bin/rspec example.rb wyjście jest:

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 

Kiedy uruchomić poprzez 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 

Więc widzisz, może zmienić kontekst specyfikacji na kilka sposobów, które pozwolą ci na poziom kontroli z linii poleceń (a więc i Jenkinsa). Chciałbyś oznaczyć specyfikacje innymi metadanymi, np. Czy można bezpiecznie je uruchomić, czy może to zająć dużo czasu.