Что считается хорошей спецификацией? Примеры Rspec для начинающих

Что считается твердой спецификацией?

Это то, что я считаю очень абстрактным о тестировании. Меня бы интересовал ответ на это на моделях, контроллерах и на все, что можно проверить. Было бы здорово иметь спецификацию для спецификации, вы знаете, что я имею в виду?

Спецификация модели должна (в порядке приоритета и релевантности):

Проверить все методы?
Проверить массив ошибок?
Проверить CRUD (и как)?
Что еще?

Спецификация контроллера/представления должна (в порядке приоритета/релевантности):

Заполните пробел...

Было бы здорово расширить этот список того, что спецификация должна и не должна содержать.

Я также хотел бы составить список трюков и предложений. Например:

Ключевое слово "should" является избыточным.

Пример:

it "should be invalid without a firstname"

будет лучше:

it "is invalid without a firstname"

Еще один трюк, используйте ожидание вместо лямбда для удобочитаемости:

lambda { ... }.should be_valid

более читаем как:

expect { ... }.should be_valid

Я составляю список полезных статей о начале работы и расскажу о них в этом сообщении по мере их поступления. Вот некоторые из них, которые я нахожу особенно полезными на данный момент. (Не стесняйтесь публиковать свои сообщения, и я буду использовать его, если это окажется полезным).

http://everydayrails.com/2012/03/19/testing-series-rspec-models-factory-girl.html http://nelvindriz.tumblr.com/post/835494714/rspec-best-practices

Было бы здорово иметь список проектов, в которых тесты были успешно реализованы. Поскольку rspec настолько читабельна (по крайней мере, что все говорят), было бы здорово получить список ссылок на проекты, которые имеют отличные характеристики для чтения.

"См. спецификации Mongoid для примера хороших характеристик." - @yfeldblum (см. ниже)

В Интернете вы найдете много статей, описывающих нереалистичные сценарии того, как тестировать основные вещи, но помимо этого вы сами сортируете. Если бы я написал статью по этой теме, я бы просто ссылался на мои тесты (например, на github), а затем тщательно комментировал одну или несколько из этих спецификаций... это похоже на лучший способ написать статью о rspec, по моему мнению. Я сделал бы это сам, но я еще не совсем там.

Если вы голосуете, чтобы закрыть это, это прекрасно, просто попробуйте оставить комментарий или предложение о том, где вы думаете, что этот пост будет принадлежать. Спасибо!

Ответ 1

Это действительно хороший вопрос, потому что, когда я начинал с тестов, я не был уверен, что считается хорошим тестовым примером. Вот несколько вещей, за которыми вы можете следовать. Этот список не мой; но составлен из нескольких источников плюс некоторые из моих дополнений.

Опишите методы

При описании методов это хорошая практика, на самом деле описывающая ваш метод: описать "#admin?". и т.д. "." является префиксом для метода класса, а "#" является префиксом для методов экземпляра.

Утверждение для каждого теста

Убедитесь, что у вас есть только одно утверждение для каждого теста. Это гарантирует, что ваши тестовые примеры чисты и понятны; что является точкой тестовых случаев, не так ли?:)

Избегайте сохранения данных в db

Вы можете динамически создавать объекты и избегать сохранения данных в db. Несмотря на то, что вы можете очистить db перед каждым тестовым случаем, "не сохранение" ускорит тестовые примеры.

@user.build(: something) вместо @user.create(: something)

Края и недопустимые случаи

Это не относится к Rspec, но важно убедиться в том, что случаи кросс-кода рассматриваются при тестировании. Это помогает значительно позже, когда ваш проект растет, и его легко поддерживать.

contexting

Я, лично, как это много в Rspec, и я на самом деле слишком злоупотребляю контекстами. Использование контекстов с условиями помогает в разделении ваших тестовых случаев. Вот пример:

# Avoid
it "should have 200 status code if user is logged in" do
  response.should respond_with 200
end
it "should have 401 status code if user is not logged in" do
  response.should respond_with 401
end

# Use
context "when user is logged in" do
  it { should respond_with 200 }
end
context "when user is logged out" do
  it { should respond_with 401 }
end

Использование темы

Если у вас много тестовых примеров, связанных с одним и тем же, вы можете использовать subject(), чтобы убедиться, что вы не повторяетесь.

# Avoid
it { assigns(:user).should be_valid }
it { assigns(:user).should_not be_dumb }
it { assigns(:user).should be_awesome }

# Use
subject { assigns("user") }
it { should be_valid }
it { should_not be_dumb }
it { should be_awesome }

Вот несколько вещей, которые я пытаюсь выполнить, когда пишу тестовые примеры. Я уверен, что есть намного больше вещей, которые могут улучшить тесты Rspec. Но этого должно быть достаточно, чтобы начать работу и написать потрясающие тестовые примеры.

Ответ 2

См. спецификации Mongoid для примера хороших характеристик.

Имеет ровно одно утверждение для примера. Не утверждайте две вещи в одном примере. Например, блок передан в it, its или specify.

Ответ 3

Я следую учебнику по изучению Ruby on Rails и преподаю Rspec как часть тестовой разработки. Поток здесь заключается в том, чтобы написать тест, который терпит неудачу, написать код для прохождения теста, а затем передать тест. Обоснование заключается в том, что, делая это, начиная с неудачного теста, вы можете быть довольно уверенным в том, что ваш код делает то, что вы ожидаете. Поэтому я полагаю, что хорошая спецификация - это тот, который гарантирует, что ваш код сделает то, что он должен. На данный момент я не получил никаких практических правил из учебника, как это написано другими плакатами.

Здесь ссылка: http://ruby.railstutorial.org/