Почему я должен использовать насмешливый фреймворк вместо подделок?

Question

Есть несколько других вариантов этого вопроса здесь, в SO, но, пожалуйста, прочитайте весь вопрос.

Используя только подделки, мы смотрим на конструктор, чтобы увидеть, какие у класса есть зависимости, и затем создаем для них подделки.

Затем мы пишем тест для метода, простоглядя на это контракт (метод подписи).Если мы не можем понять, как таким образом протестировать метод, не следует ли нам попытаться реорганизовать метод (скорее всего, разбить его на более мелкие части), чем заглянуть внутрь него, чтобы понять, как мы должны его тестировать?Другими словами, это также дает нам контроль качества.

Разве это не плохо, потому что они требуют, чтобы мы заглянули внутрь метода, который мы собираемся протестировать?И поэтому пропустите весь «посмотрите на подпись как на критика».

Обновление, чтобы ответить на комментарий

Тогда произнесите заглушку (просто фиктивный класс, предоставляющий запрошенныйобъекты).

Фреймворк, подобный Moq, обеспечивает вызов Method A с аргументами X и Y.И чтобы иметь возможность настроить эти проверки, нужно заглянуть внутрь проверенного метода.

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

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

Answer 1

Это немного серая зона, и я думаю, что есть некоторые совпадения.В целом я бы сказал, что использование фиктивных объектов для меня предпочтительнее.

Полагаю, что отчасти это зависит от того, как вы проводите тестирование кода - сначала тестирование или код?

Если вы следуете тестууправляемый план проектирования с объектами, реализующими интерфейсы, тогда вы эффективно создаете фиктивный объект на ходу.

Каждый тест рассматривает тестируемый объект / метод как черный ящик.

Он фокусируется на написании более простого кода метода, в котором вы знаете, какой ответ вам нужен.

Но, кроме всего прочего, он позволяет вам иметь исполняемый код, который использует фиктивные объекты для неписанных областей кода.

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

Answer 2

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

Что касается насмешек по сравнению с заглушками, я обычно (не всегда) обнаруживает, что издевательства обеспечивают более четкие тесты и (необязательно) более детальный контроль над ожиданиями.Однако макеты могут быть слишком мощными, что позволяет вам тестировать реализацию до уровня, при котором изменяемая реализация тестирует, оставляя результат неизменным, но тест не пройден.

Answer 3

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

string readDoc(name, fileManager) { return fileManager.Read(name).ToString() }

Здесь вы можете напрямую проверить возвращаемое значение, так что заглушка работает отлично.

void saveDoc(doc, fileManager) { fileManager.Save(doc) }

здесь вы бы очень хотели проверить, был ли вызван метод Save с правильными аргументами (doc).Содержание документа не меняется, fileManager ничего не выводит.Это связано с тем, что проверяемый метод зависит от некоторых других функций, предоставляемых interface .Интерфейс - это контракт, поэтому вы не только хотите проверить, дает ли ваш метод правильные результаты.Вы также проверяете, правильно ли он использует предоставленный контракт.

Answer 4

Я вижу это немного по-другому.Позвольте мне объяснить мою точку зрения:

Я использую фальшивые рамки.Когда я пытаюсь протестировать класс, чтобы убедиться, что он работает должным образом, я должен проверить все возможные ситуации.Когда в моем тестируемом классе используются другие классы, я должен убедиться в том, что в определенной тестовой ситуации специальные исключения вызываются используемым классом или определенным возвращаемым значением и т. Д. Это вряд ли имитирует реальные реализации этих классов.классы, поэтому я должен написать подделки из них.Но я думаю, что в случае использования подделок, тесты не так легко понять.В своих тестах я использую MOQ-Framework и в моём методе тестирования есть настройки для макетов.В случае, если мне нужно проанализировать мой метод испытаний, я могу легко увидеть, как настроены макеты, и мне не нужно переключаться на кодирование подделок, чтобы понять тест.

Надеюсь, что это поможет вам найти свой ответ ...