Тестирование API сервисов и RSpec

[vanburg]

Переменные класса в спеках — плохая практика, используйте "#let/#let!" (в данном случае последний)

[unabl4]

В чём явное преимущество использования mockserver-а перед, скажем, тем же webmock?

Как-то слишком много танцев с бубном ради непонятно какой выгоды.
Мало того, что кода для тестов больше, чем самого проверяемого кода, так он ещё и раскидан по разным местам, что может усложнить жизнь в будущем — как для понимания принципа работы тестов, так и для изменения.

Код для тестов в моём понимании должен быть как можно более простым, понятным, лаконичным и главное — содержаться в одном месте как одна логическая единица, пусть даже ценой копи-паста.

[ZurgInq]

WebMock работает только на уровни Ruby, MockServer запускается независимо. При этом если не хочется тянуть java можно найти аналоги.

Код тестов больше проверяемого кода — типичная картина, когда соотношение строк тестов к коду достигает 3:1. А в данном случае значительный объём кода теста занимает работа с MockServer, что легко выносится в отдельные файлы хелперы.

Выгода — при переписывание условного микросервиса с языка X на язык Y, код тестов и тестовый набор данных не теряется.

[unabl4]

Вот тут есть момент, который от меня явно ускользает.
Зачем тестировать отдельно взятый микросервис из другого (или других) микросервиса(ов)?
Мне кажется, это какая-то попытка решить несуществующую проблему. Каждый микросервис должен быть написан, задеплоен и покрыт тестами изолированно. А коммуникация между микросервисами в тестах должна мокаться (с помощью того же webmock). Ну это моё мнение.

[ZurgInq]

Сервис не тестируется из другого сервиса. Сервис тестируется из другого кода. В простейшем случае это могут быть bash скрипты с curl запросами внутри. И такая практика реально существует, примеры проектов\репозиториев сейчас с ходу не приведу.
В данном примере есть микросервис написанный на go, и автоматизированные тесты написанные на ruby. Сбоку добавлен mockserver, как альтернатива встроенным в языки мокам\стабам, т.к. в данном случае WebMock и иже с ним работать не будут.

[unabl4]

Как мне кажется, это не принципиальное различие — из другого кода или из другого (микро-) сервиса происходит тестирование. Только если наша цель иметь тесты в другом месте и возможность написать их на другом языке/фреймворке/whatever, таким можно заморочиться. Всё остальное будет причинять неудобства, как мне это видится.

[ZurgInq]

del — перенесёно в ветку выше

[KriMs]

before { @response = RestClient.get "#{api_server_host}/ping" }

Так не стоит делать, а тем более использовать инстансные переменные. У вас это subject.
И код будет выглядеть так:

describe "GET /ping" do
    subject { RestClient.get "#{api_server_host}/ping" }

    it 'returns correct response' do
        expect(subject.code).to eq(200)
        expect(subject.body).to eq('OK')
    end
end

Если уж хочется, то можно сделать именованный subject: subject(:response)

Так же если не задаете имя теста(того, чего вы ожидаете), то нужно использовать не it, а specify

[ZurgInq]

Спасибо, про именованные subject не знал.