Как сохранить Mock-объект в синхронизации с целевым объектом

Question

Я спрашиваю об управлении фиктивными объектами, независимо от конкретной реализации (EasyMock, Mock Object и т. Д.).

Я неохотно использую объект Mock в своих модульных тестах по следующей причине: ПоведениеИмитируемый объект должен отражать поведение объекта, который подвергается насмешке.Если изменилось поведение объекта, который нужно смоделировать, нам также придется изменить поведение объекта, который имитируется.Если мы этого не сделаем, поведение фиктивного объекта будет не синхронизировано с реальным объектом и, таким образом, сделает бессмысленным юнит-тестирование, и это опасно.

Мой вопрос: как сохранить фиктивный объект всинхронизировать с целевым объектом?Как вы распространяете изменения?Используете ли вы какую-либо технику управления ложными объектами?

Редактировать: изменить заголовок, чтобы сузить область действия.

Answer 1

Четко определенные API не должны иметь такого рода свободу действий: учитывая набор входных данных, объект, который должен быть смоделирован, должен вести себя только этими конкретными способами: поведение привязано к интерфейсу.Если допускается отклонение, то ваш фиктивный объект должен тестировать все различные вещи, которые этот объект может сделать.

Вы можете снизить риск отклонения поведения с помощью:

• Интеграционное тестированиеи
• Сравнение ваших смоделированных данных с реальной реализацией.

Answer 2

Если ClassA звонит:

 AThing aThing = ClassB.GiveMeAThing()

ClassA никогда не должно интересоваться, как ClassB получает эту вещь.Таким образом, заглушка - StubB - никогда не должна заботиться о том, как ведет себя реальная реализация заглушки.Только если само взаимодействие изменяется - тип возвращаемого значения или вызывающие аргументы - следует менять StubB, и это понадобится, если вы хотите, чтобы ваш код компилировался :-)

В случае, если вашClassB начинает возвращать Null или Throws новые типы исключений;Что ж, тогда нужно написать совершенно новые тесты и, возможно, новые заглушки.

С уважением, Мортен

Answer 3

Я не эксперт, но я думаю, что фиктивный объект предназначен для одного теста / взаимодействия.И если это взаимодействие изменится, вы, очевидно, захотите, чтобы это отразилось в ваших тестах.Но это не должно нарушать все фиктивные объекты класса, поскольку они проверяют различные взаимодействия, которые все еще могут быть действительными.

Answer 4

Вы на правильном пути.Вам не нужны хрупкие тесты, которые нужно менять каждый раз, когда вы реорганизуете тестируемую систему.

В общем, я концентрирую свои тесты на общедоступном интерфейсе.Если ваш публичный интерфейс меняется, вам, вероятно, придется изменить не только тесты.

Я также стараюсь проводить тестирование состояния вместо тестирования поведения, когда это возможно.Поэтому я обычно использую заглушки вместо макетов .(Большинство изолирующих / насмешливых фреймворков позволяют вам создавать либо.) Я проверяю состояние тестируемой системы (или класса), а не прошу фиктивный объект проверить себя.

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

РЕДАКТИРОВАТЬ : См. Также эту статью Скотта Бэйна .