VV
почему?))
Вкратце: потому что с ними возни потом много, по сути, моки и стабы — следы реализации в тесте, теряется концепция "черной коробки". Поменял функционал, надо менять и тест.
Size: a a a
2020 April 03
A7
Наша самая успешная выпускница (тим лид в AirBnB) — девушка. Се ля ви. И она за такие слова "типа женщины — влюбчивый, верный, творческий, мужчины — простота, логика" вам бы сейчас предъявила очень серьезно.
Она наверное среди мужиков выросла ))
VV
почему? если я юнит пишу?
А
Вкратце: потому что с ними возни потом много, по сути, моки и стабы — следы реализации в тесте, теряется концепция "черной коробки". Поменял функционал, надо менять и тест.
Ну смотри, допустим я пишу юнит тест для класса:
class Test
def initialize(ar_obj)
@x = ar_obj
end
def do_something
@x.get_something
end
end
Я буду мокать ar_obj И это наоборот мне позволит абстрагироваться от Active Record и сделать юниты стабильнее. Разве нет?
class Test
def initialize(ar_obj)
@x = ar_obj
end
def do_something
@x.get_something
end
end
Я буду мокать ar_obj И это наоборот мне позволит абстрагироваться от Active Record и сделать юниты стабильнее. Разве нет?
VV
Ну смотри, допустим я пишу юнит тест для класса:
class Test
def initialize(ar_obj)
@x = ar_obj
end
def do_something
@x.get_something
end
end
Я буду мокать ar_obj И это наоборот мне позволит абстрагироваться от Active Record и сделать юниты стабильнее. Разве нет?
class Test
def initialize(ar_obj)
@x = ar_obj
end
def do_something
@x.get_something
end
end
Я буду мокать ar_obj И это наоборот мне позволит абстрагироваться от Active Record и сделать юниты стабильнее. Разве нет?
И как будет выглядеть тест?
M
Ну смотри, допустим я пишу юнит тест для класса:
class Test
def initialize(ar_obj)
@x = ar_obj
end
def do_something
@x.get_something
end
end
Я буду мокать ar_obj И это наоборот мне позволит абстрагироваться от Active Record и сделать юниты стабильнее. Разве нет?
class Test
def initialize(ar_obj)
@x = ar_obj
end
def do_something
@x.get_something
end
end
Я буду мокать ar_obj И это наоборот мне позволит абстрагироваться от Active Record и сделать юниты стабильнее. Разве нет?
здесь у вас конструктор - часть публичного интерфейса - вы ar_obj не мокаете строго говоря, а просто передаете нужный для тестирования класса объект
А
И как будет выглядеть тест?
subject { Test.new(ar_obj_mock) }
let(:ar_obj_mock) { double(get_something: :expected_result) } типа такого
let(:ar_obj_mock) { double(get_something: :expected_result) } типа такого
VV
Ну вот представьте теперь, что решили доставать те же данные, используя другой метод AR:
def do_something
@x.get_something_else
end
VV
Например, было с
find_by(...), а стало с where(...).firstVV
Можно, но это не точно :)
А
Например, было с
find_by(...), а стало с where(...).firstмой тест повалится и я пойду его переписывать, разве это плохо?
VV
Например, было с
find_by(...), а стало с where(...).firstИ тебе придется переписывать тест, он по сути тестирует не возвращаемое значение метода, а то, что метод дернул нужный метод у объекта
VV
мой тест повалится и я пойду его переписывать, разве это плохо?
ну эээ именно про это я и говорю, что вы поменяли реализацию (при этом на выходе может быть тот же самый р-т), а тест повалился
VV
терябется концепция "черного ящика" (тестируем метод, не зная, как он устроен)
VV
Тесты в т.ч. нужны, чтобы рефакторить проще было. Поправил реализацию метода, прогнал тесты, если прошли — всё ок. А тут получается, каждый раз надо будет править и тесты тоже. Хотя функционал может и не поменяться.
VV
Но я не настаиваю, типа "откажитесь от моков совсем"