Комментарии 16
Рекомендую книгу Rails 4 Test Prescriptions: Build a Healthy Codebase. Хорошая база для тех, кто пишет тесты (не только в Rails).
Вы мне простую вещь объясните: почему в рельсах до сих пор нет механизма мультисессионного тестирования?
Т.е. что бы из одного теста можно было ходить к серверу от разных пользователей?
Т.е. что бы из одного теста можно было ходить к серверу от разных пользователей?
Какие именно сценарии интересуют? Самому пока не приходилось писать, но по-быстрому нагуглилось, что капибара, например, так может: blog.bruzilla.com/2012/04/10/using-multiple-capybara-sessions-in-rspec-request.html
Мне кажется, что с type: :request, тоже не должно быть проблем, но надо проверять.
Мне кажется, что с type: :request, тоже не должно быть проблем, но надо проверять.
sess1 = new_session sess1.post "/login", email: "...", password: "..." sess1.should redirect_to ... reply = sess1.get "/messages" ... sess2 = new_session sess2.post "/messages", ... sess1.get ...
Я про такое. Вместо такого есть только неведомая херня с предложением предзаполнять данные в базе из фикстур.
Вместо такого можно писать:
Т.е. в этом конкретном примере, мне кажется, нет необходимости в том, чтобы создавать сообщение другого пользователя внутри теста Проверять всё по-отдельности. Минусов от того, чтобы разнести проверки по разным тестам, я не вижу. Если же нужны большие интеграционные тесты каких-нибудь интерактивных фич, то пример из ссылки выше вроде подходит.
Напишите, пожалуйста, где можно посмотреть примеры на других языках того, что вы имеете в виду.
sign_in { create(:user) }
let(:other_user) { create(:user) }
let!(:own_message) { create(:message, user: current_user) }
let!(:other_message) { create(:message, user: other_user) }
its(:body) { should contain other_message.text }
its(:body) { should contain own_message.text }
Т.е. в этом конкретном примере, мне кажется, нет необходимости в том, чтобы создавать сообщение другого пользователя внутри теста Проверять всё по-отдельности. Минусов от того, чтобы разнести проверки по разным тестам, я не вижу. Если же нужны большие интеграционные тесты каких-нибудь интерактивных фич, то пример из ссылки выше вроде подходит.
Напишите, пожалуйста, где можно посмотреть примеры на других языках того, что вы имеете в виду.
конечно не можно.
Ваш тест совершенно не о том, вы тестируете работу системы в абсолютно однопользовательском режиме. Я говорю про написание высокоуровневых тестов по работе одновременно нескольких пользователей.
Я совершенно не приемлю искуственные игрушечные тесты в которых сначала из фикстур что-то заливается, потом начинаем якобы постить данные, глубоко влезая во внутренние структуры. Тестировать надо прежде всего то, что будет дергать пользователь, от этого есть польза.
Ваш тест совершенно не о том, вы тестируете работу системы в абсолютно однопользовательском режиме. Я говорю про написание высокоуровневых тестов по работе одновременно нескольких пользователей.
Я совершенно не приемлю искуственные игрушечные тесты в которых сначала из фикстур что-то заливается, потом начинаем якобы постить данные, глубоко влезая во внутренние структуры. Тестировать надо прежде всего то, что будет дергать пользователь, от этого есть польза.
Все давно есть github.com/grosser/parallel_tests и отлично работает.
параллельный прогон тестов — это вообще не о том.
Т.е это безусловно необходимая вещь, что бы полноценно тестировать наведенные баги и без параллельных рандомизированных тестов это всё детский лепет, но я говорил о другом, я говорил именно о возможности из одного теста иметь возможность спокойно ходить к рельсам как бы от разных юзеров
Т.е это безусловно необходимая вещь, что бы полноценно тестировать наведенные баги и без параллельных рандомизированных тестов это всё детский лепет, но я говорил о другом, я говорил именно о возможности из одного теста иметь возможность спокойно ходить к рельсам как бы от разных юзеров
Многими вещами из статьи пользуюсь. Но вот как только начинаю писать shared examples — так все, тесты становятся едва ли не сложнее кода, который они тестируют. Вот ваш пример с опциональными колбеками — это уже излишняя (на мой взгляд) сложность. Код такого теста с первого взгляда не выглядит как код теста.
А и еще, если --require rails_helper внести в .rspec, то он будет включен везде, а именно этого разработчики хотели избежать, разделив на spec_helper и rails_helper: есть тесты, которым не нужны рельсы, и они будут выполняться очень быстро. Об этом написанно в комментариях в spec_helper
А и еще, если --require rails_helper внести в .rspec, то он будет включен везде, а именно этого разработчики хотели избежать, разделив на spec_helper и rails_helper: есть тесты, которым не нужны рельсы, и они будут выполняться очень быстро. Об этом написанно в комментариях в spec_helper
Я надеюсь, все понимают, что будет делать `--require`, и какие от этого могут быть последствия. Конечно, в рельсовых приложениях бывают тесты, которые не зависят от application/rails. На моей памяти таких небольшое количество. Да, в некоторых случаях пользы от моего предложения не будет.
Добавлю только, что, если тесты не используют rails_helper, то, скорее всего, надо будет в каждом таком файле писать все require, самому поддерживать $: в актуальном состоянии в spec_helper. Ничего плохого в этом нет, просто об этом надо помнить.
Добавлю только, что, если тесты не используют rails_helper, то, скорее всего, надо будет в каждом таком файле писать все require, самому поддерживать $: в актуальном состоянии в spec_helper. Ничего плохого в этом нет, просто об этом надо помнить.
1. Это же Ruby, тут можно опускать скобочки и будет красивее
вместо
можно писать
2. should уже давно не рекомендуют использовать, тем более не красиво смешивать вместе с expect
github.com/rspec/rspec-expectations/blob/master/Should.md
3. Стоит использовать встроенные проверки
вместо
можно
4. К полезным мелочам я бы еще добавил в .rspec
очень приятная мелочь при выводе сообщений
вместо
super().merge!(name: '')
можно писать
super.merge!(name: '')
2. should уже давно не рекомендуют использовать, тем более не красиво смешивать вместе с expect
In version 2.11 expect method was introduced which is now the recommended way to define expectations on an object.
github.com/rspec/rspec-expectations/blob/master/Should.md
3. Стоит использовать встроенные проверки
вместо
is_expected.to eq true
можно
is_expected.to be_truthy
4. К полезным мелочам я бы еще добавил в .rspec
--format documentation
очень приятная мелочь при выводе сообщений
1. нельзя. попробуйте.
2. should не рекомендуется в `x.should eq 5`, т.к. нужен манки-патч. `it { should… }` не требует, и его никто не запрещает. Смешивается, да, но плюсов по сравнению с `is_expected.to`, не вижу.
3. Разные вещи.
4. На 100+ тестах уже не удобно. Предпочитаю
2. should не рекомендуется в `x.should eq 5`, т.к. нужен манки-патч. `it { should… }` не требует, и его никто не запрещает. Смешивается, да, но плюсов по сравнению с `is_expected.to`, не вижу.
3. Разные вещи.
4. На 100+ тестах уже не удобно. Предпочитаю
# spec_helper.rb
if config.files_to_run.one?
config.default_formatter = 'doc'
end
стандартный вопрос на собеседовании: чем отличается super от super()
3. или просто: .to be
4. или короче: -fd, и полезно с --dry-run
4. или короче: -fd, и полезно с --dry-run
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рецепты тестирования Ruby и Rails приложений