Передовые практики для интеграционных тестов для внешних конечных точек приложения rails?

Question

Я буду кратким, у меня есть приложение rails, которое взаимодействует с другими приложениями, некоторые из которых используют SOAP (конечно, не-rails приложения ...), а другие - с REST.Я делаю интеграционные тесты, чтобы убедиться, что мои классы-обертки конечных точек имеют правильные отображения и настройки.Однако по умолчанию они выполняются rake test, что делает его медленным и хрупким.Я хочу часто проводить модульные тесты и интеграционные тесты только по требованию.Как вы это делаете?

Каковы ваши предпочтения в отношении такого интеграционного тестирования?

• Насколько глубоко вы юнит-тестирование и / или издеваетесь?
• Вы реплицируете целые ответы SOAP или REST xml в заглушки?
• Вы вообще создаете интеграционные тесты "внешней конечной точки"?

Обновление В: Как исключить каталог-тест при запуске rake test?

Answer 1

Если вы придерживаетесь того, что предлагают ребята из Rspec / Cucumber, то уровень тестов интеграции является неподходящим местом для насмешки над вашими данными, потому что в некоторых отношениях он противоречит цели теста интеграции / приемки.Тем не менее, у вас есть , чтобы высмеивать такие вещи, как транзакции PayPal, верно?В моем текущем проекте я сталкиваюсь со многим этим, и вот некоторые из решений, которые я внедряю:

1. Тестирование тегов, которые не работают в определенных контекстах.В моем примере многие серверы живут за брандмауэрами, поэтому мои тесты не проходят, если я дома и не использую vpn.Итак, в огурце я могу пометить их как @firewall и сказать ему запускать тесты, которые не помечены как firewall.Я уверен, что Rspec 2.0 также поддерживает эту функцию.

2. Запросы на обслуживание Mocking.Да, это, вероятно, плохая идея, но я не знаю, как сделать это иначе с любой предсказуемостью.У меня есть отдельный набор тестов, чтобы подтвердить, что сервисы запущены, и из моего приложения rails я предполагаю, что они работают должным образом.Примером этого может быть LDAP.И да, в этих условиях я склонен использовать реальный ответ и делать что-то подобное.response = double('response') ; response.expects(:data).and_returns('my xml here')

3. Я думаю, независимо от сложности системы, что тесты конечной точки действительно важны.Я действительно наслаждаюсь огурцом, он дает мне 95% того, что мне нужно делать в функциональных тестах, и поэтому я заканчиваю тем, что пишу меньше этих тестов и больше тестов всего рабочего процесса.

Answer 2

Решение VCR .

Answer 3

Вы должны написать тонкий слой вокруг внешних API (Facade / Wrapper) и использовать vcr-gem , чтобы "заглушить" сетевые вызовы.Вы можете получить больше информации из моей статьи об архитектуре rails test .

Answer 4

За исключением тестов интеграции конечной точки из rake test и возможности изолировать и запускать их с rake test:endpoints, было решено всего несколько строк кода.Должен признать, что я провел много часов, ругаясь и ругаясь.Там должно быть больше документации и объяснений в источнике рельсов.Подобный код на Ruby, как правило, не очень понятен, ИМО.

Ну, вот и все: создайте свою задачу: lib / tasks / slow_tests.rake

require 'rails/test_unit/railtie'
desc "Runs all endpoint integration tests."
namespace :test do

  #hooks on to the test task through the 'test:prepare'
  #For details, check the railties gem (v3.0+) lib/rails/test_unit/testing.rake,
  #look for "task :test" and "namespace :test"
  TestTaskWithoutDescription.new(:endpoints => 'test:prepare') do |t|
    t.libs << 'test'
    t.pattern = 'test/endpoints/**/*_test.rb'
  end
end

Теперь я могупоместите мои хрупкие интеграционные тесты конечных точек в каталог test / enpoints, выполняя их всякий раз, когда я хочу (не часто)

Примечание: это предполагает test / unit или musta.