Комментарии 3
Всё сильно упростилось, верно?
Не верно.
Вы перешли от тестирования поведения к тестированию реализации (т.е. получили более хрупкий тест, который будет ломаться при рефакторингах внутреннего устройства тестируемого объекта, даже если его внешнее API и поведение не меняется).
Код стал менее очевиден и более подвержен ошибкам (легко забыть сделать вызов через
.this, потому что и без него всё сработает не хуже).В публичное API тестируемого типа вылезли ручки связанные с тестированием. Этого не всегда получается избежать, но во-первых тут точно нечем гордиться, и во-вторых надо хотя бы стараться их маскировать под штатный функционал (хотя бы в теории полезный не только в тестах).
Хуже всего, что Вы предлагаете это решение как паттерн, что может привести к большой куче
.thisв разных проектах, от чего их код явно не станет лучше. Правильные тесты должны делать код и архитектуру чище, а не создавать лишние нагромождения внутри тестируемого кода.
Обычно желание реализовать нечто подобное возникает из-за проблемы совсем в другом месте: тестируемый объект слишком сложен и запутан, насколько, что тестировать его целиком, даже при наличии моков всех используемых им объектов, стало слишком сложно. Решением этой проблемы является рефакторинг сложного объекта пока он не развалится на несколько достаточно простых.
Всё сильно упростилось, верно?
Не верно
Да нет, всё верно. 🙂
Вы перешли от тестирования поведения к тестированию реализации
В публичное API тестируемого типа вылезли ручки связанные с тестированием
Не вылезли, опять же, они там были. Если держаться в рамках статьи.
В примере разве сказано, что у нас есть неэкспортированные методы, которые мы сделали экспортированными? Нет. Получается, что у нас были уже экспортированные методы. Значит они уже с тестами.
А отсюда получается, что если надо сделать дополнительные методы, которые по какому-то стечению обстоятельств среди прочего вызывают другие экспортированные методы, но не изолировать эти вызовы, то мы получим тестирование одного через другое. Другими словами тестировать A, B, C через D, когда тесты для A, B, C уже есть. И вот это – неправильно и хрупко.
забыть сделать вызов через
.this
Как это можно забыть, если вы этот вызов изолируете и ожидаете вызов в тесте?
Хуже всего, что Вы предлагаете это решение как паттерн
Даже в мыслях не было.
Ну и в целом, да, я согласен вот с этим вот всем, что плохо, когда вы выносите на верх, тестируете детали реализации, про то, что надо хорошо рефакторить, правильно разделять и бла-бла.
Но эта статья не про это.
Эта статья про изоляцию вложенных вызовов. Это про приём избавляющий от проблем, когда вы имеете на руках вложенные вызовы.
Этого не всегда получается избежать
Вот именно. Да.
del
[Go] Изоляция вложенных вызовов в юнит-тестах