AR
ну и с новым проектом))
Спасибо!)
Size: a a a
2020 June 05
w
т.е в ряде случаев он помогает, но злоупотреблять им не стоит, т.к. может привести к протечке состояния (state leaking) и вы потом будете долго ломать голову почему определенный тест падает только в 10% случаях, а на самом деле другой тест перед ним испортил state
ну да, нужная штука, когда ты хочешь все же сложный сетап соорудить, но один раз, и оно будет по всему тесту использоваться
АШ
тогда лучше фикстуры
АШ
если это что-то глобальное
АШ
например, список стран
w
чем фикстуры помогут, если тебе нужно сделать сложную выборку?
АШ
ну сложная выборка она же не в каждом тесте
АШ
т.е. если что-то используется везде - фикстура
если что-то сложное только в одной спеке - let_it_be
иначе let
если что-то сложное только в одной спеке - let_it_be
иначе let
w
я имел ввиду в одном контексте тебе нужно протестить несколько веток ифов. например, наличие пачки фильтров в квери объекте
АШ
хм, а как здесь let_it_be поможет?
АШ
чтобы заинсертить данные разве что только в начале
w
да, чтобы просто предсоздать все данные, которые не нужно чистить после прохождения одного спека, пусть будут для пачки следующих тестов
w
сорян, что так непонятно выражаюсь
f🤔
Доброе утро! Такой вопрос. Как использование фабрик и let влияет на скорость прохождения тестов? Пришла на проект где все оч плохо и это не используют, буду рефакторить. Знаю что тесты будут более изолированными, однако интересно что там именно со скоростью
оффтопик (не про скорость исполнения)
еще один очень полезный инструмент по борьбе с плавающими тестами в легаси я давно подсмотрел у гитлаба, про анти-*_any_instance_of в виде *_next_instance_of в местах, где без него не обойтись
https://docs.gitlab.com/ee/development/gotchas.html#avoid-using-expect_any_instance_of-or-allow_any_instance_of-in-rspec
еще один очень полезный инструмент по борьбе с плавающими тестами в легаси я давно подсмотрел у гитлаба, про анти-*_any_instance_of в виде *_next_instance_of в местах, где без него не обойтись
https://docs.gitlab.com/ee/development/gotchas.html#avoid-using-expect_any_instance_of-or-allow_any_instance_of-in-rspec
AR
оффтопик (не про скорость исполнения)
еще один очень полезный инструмент по борьбе с плавающими тестами в легаси я давно подсмотрел у гитлаба, про анти-*_any_instance_of в виде *_next_instance_of в местах, где без него не обойтись
https://docs.gitlab.com/ee/development/gotchas.html#avoid-using-expect_any_instance_of-or-allow_any_instance_of-in-rspec
еще один очень полезный инструмент по борьбе с плавающими тестами в легаси я давно подсмотрел у гитлаба, про анти-*_any_instance_of в виде *_next_instance_of в местах, где без него не обойтись
https://docs.gitlab.com/ee/development/gotchas.html#avoid-using-expect_any_instance_of-or-allow_any_instance_of-in-rspec
👍
CM
я вот до сих пор не выкупаю эту тему с allow_any_instance_of т.к. за все годы ни разу в ногу не выстрелило. как выглядит код+спека, что эта штука мешает жить?
AR
Кстати та же фигня. Юзаю редко, но иногда требуется. Никогда проблем не возникало
NB
Согласен, но в целом предпочитаю instance_spy + allow().to receive(:method).and_return(spy)
но и с тем и с тем пока ни разу проблем не было
но и с тем и с тем пока ни разу проблем не было
AR
Согласен, но в целом предпочитаю instance_spy + allow().to receive(:method).and_return(spy)
но и с тем и с тем пока ни разу проблем не было
но и с тем и с тем пока ни разу проблем не было
Воу, ни разу такого не видела