Люблю осознавать относительность рекомендаций по дизайну и паттернам, находя частично или полностью противоречащие друг другу статьи от гуру нашей индустрии. Сегодня поговорим про Structural Inspection.

Structural Inspection

Structural Inspection это подход, применяемый для написания unit-тестов для сложных систем, при котором сначала по-отдельности тестируются составные компоненты, а затем проверяется, что они правильно взаимодействуют между собой. Марк Симан находит эту технику весьма полезной. В статье Марк без раскачки использует паттерн Посетитель. На всякий случай, вот эта статья очень хорошо его объясняет.

В качестве примера Марк использует интернет магазин, в котором покупатель может добавить ряд продуктов в корзину и получить общую сумму покупки. При этом общая цена складывается из

  • стоимости товаров, умноженной на их количество
  • оптовой скидки (при достижении определенного количества товаров)
  • налога

Реализация производится при помощи цепочки посетителей (basket pipline), каждый из которых меняет итоговую сумму в корзине по своим бизнес-правилам. Для применения оптовой скидки используемVolumeDiscountVisitor, для начисления налога - VatVisitor и т.д. Посетители в цепочке вызываются последовательно и результаты работы отработавшего передаются “на вход” следующему.

Один из вариантов протестировать такое приложение - использовать Structural Inspection. Для этого отдельно тестируется каждый из посетителей, а затем проверяется структура цепочки. С тестирование отдельных частей все понятно, а вот проверка структуры фасада (цепочки посетителей в нашем случае) - это “фишка” Structural Inspection.

Бизнес-правила говорят нам, что налог нужно начислять на сумму после применения к ней скидки. То есть порядок вызовов посетителей в цепочке имеет значение. Именно порядок следования посетителей и проверяется в тестах Марка (в дополнении к тестам посетителей как таковых). В своем курсе на Pluralsight, Симан показывает больше тестов и в целом освещает тему намного лучше, чем в статье. Рекомендую прослушать, у Pluralsight есть триал ;)

На слайдах своего курса Марк сообщает, что ему пришлось написать 80 тестов для того, чтобы осуществить Structural Inspection своего кода. А также признает, что это “too enterprisey” для простой корзины с товарами. Однако, это будет вполне оправдано, если придется принимать во внимание стоимость доставки, которая будет учитывать габариты и вес товаров и пункт назначения, а налог будет рассчитываться исходя из категории товаров.

Structural Inspection - антипаттерн?

А вот автор известного блога Enterprise Craftsmanship, Владимир Хориков называет Structural Inspection антипаттерном. Причина проста - если мы захотим провести рефакторинг реализации - нам придется обновлять и тесты. Вместо того, чтобы анализировать детали реализации тестируемого класса (sut) Владимир предлагает проверять только результат его работы. Звучит заманчиво, это вам не 80 тестов писать.

Выводы

Мне самому не доводилось использовать Structural Inspection в своих проектах. Сама идея разбить сложную систему на простые части и протестировать сначала их, а затем проверить, правильно ли они связаны звучит вполне логично. Но складывается ощущение, что занятие это очень трудоемкое, а также тяжело поддерживаемое. Однако, почему бы не воспользоваться этой техникой в критически важных частях системы?