Спецификация запроса API против спецификации запроса - PullRequest
Новая
       26

Спецификация запроса API против спецификации запроса

1 голос
/ 04 июля 2019

Я тестирую новичка, проходящего через Everyday Rails Testing с книгой RSpec.

В основном есть два файла спецификации запроса - один для API: 

# spec/requests/projects_api_spec.rb

describe 'Projects API', type: :request do
  it 'creates a project' do
    user = FactoryBot.create(:user)
    project_attributes = FactoryBot.attributes_for(:project)

    expect {
        post api_projects_path, params: {
          user_email: user.email,
          user_token: user.authentication_token,
          project: project_attributes
        }
    }.to change(user.projects, :count).by(1)

    expect(response).to have_http_status(:success)
  end
end

А другой заменаспецификация контроллера: 

# spec/requests/projects_spec.rb

RSpec.describe "Projects", type: :request do
  context "as an authenticated user" do
    before do
      @user = FactoryBot.create(:user)
    end

    context "with valid attributes" do
      it "adds a project" do
        project_params = FactoryBot.attributes_for(:project)
        sign_in @user
        expect {
          post projects_path, params: { project: project_params }
        }.to change(@user.projects, :count).by(1)
      end
    end
  end
end

Разве мы не можем просто провести один интеграционный тест или запросить спецификацию?

1 Ответ

1 голос
/ 04 июля 2019

Они тестируют разные конечные точки (api_projects_path и projects_path) и имеют разные методы авторизации.

Даже если тесты (здесь «тесты» предназначены для отдельных тестов, или блоков it), являются или выглядят в основномидентичные - в конечном итоге они могут расходиться.А для API важно сохранить поведение.Что касается организации файлов - конечно, они могут быть помещены в один файл и совместно использовать некоторые общие настройки (следуя принципу СУХОЙ).

Но с другой стороны - для лучшего разделения и стабильности API некоторые программы копирования-вставки-программированияприемлемо - таким образом вы с меньшей вероятностью непреднамеренно измените тесты API при реализации некоторых изменений в пути без API-интерфейса в будущем.

...