В чем разница между gtest и gmock?
Я пытаюсь понять цель google-mock, Google C ++ фреймворк.
Я уже работал с gtest раньше, но все же я не могу понять, что gmock является. Зачем нам это нужно?
gtest используется для модульного тестирования. Что нам нужно gmock тогда, если gmock требуется для unit testing?
Решение
«Google Mock сам по себе не является фреймворком для тестирования. Вместо этого ему нужен фреймворк для написания тестов. Google Mock без проблем работает с Google Test. Он поставляется с копией Google Test в комплекте. Начиная с версии 1.1.0, вы также можете использовать это с любой платформой тестирования C ++ по вашему выбору. «- Google Mock, Системные требования
Макет подобен объектам, определенным таким образом, чтобы имитировать реальную сделку, обеспечивая контролируемое поведение. Например, чтобы протестировать биржевое приложение, вы должны создать фальшивый провайдер биржевых данных, который создал бы фальшивые биржевые котировки, чтобы протестировать ваш код. Подумайте о слове mock, буквально означает «подражать».
Другие решения
Программные блоки не живут на зеленых лугах. Им очень часто нужны коллеги для работы. В реальной системе эти аналоги принадлежат самой системе. В модульных тестах они заменены на макеты.
Gtest является основой для модульного тестирования.
Gmock — это фреймворк, имитирующий остальную часть вашей системы во время юнит-тестов.
Предположим, вы пишете фрагмент кода, который должен взаимодействовать с непредсказуемой, дорогой внешней системой (например, веб-сайтом, большой базой данных, физическим датчиком и т. Д.). Ваш код должен продолжать работать, когда время ожидания внешней системы истекло. , либо выдает сообщения об ошибках, либо выдает противоречивые данные. Как вы можете проверить, действительно ли ваш код соответствует этим требованиям?
Ну, вы можете запускать его с реальным веб-сайтом / базой данных / датчиком / чем угодно, целую кучу раз и надеяться, что вам повезет со всеми ошибочными условиями, которые должен обрабатывать ваш код. Очевидно, довольно дорогая и ненадежная стратегия тестирования.
Таким образом, вместо этого вы пишете что-то, что удовлетворяет тому же интерфейсу, что и веб-сайт / база данных / датчик / что угодно, но которое вы запрограммировали для получения определенных «постоянных» ответов (ошибки, тайм-ауты, противоречивые данные и т. Д.). Теперь ваши тесты будут работать намного быстрее (потому что они не сталкиваются с накладными реальный Веб-сайт / база данных / датчик / что угодно), и они предсказуемы. К сожалению, для написания отдельного «фиктивного» веб-сайта / базы данных / датчика / чего угодно, требуется много кода для каждого сценария, который нужно протестировать. Чем больше работы, тем меньше вероятность, что вы это сделаете. Результат: неадекватно проверенный код.
Gmock и его родственники автоматизируют многие из этих вещей, так что вы можете указать желаемое «стандартное» поведение в середине самого теста, затратив всего несколько строк кода. Если тесты просты в написании, вы, скорее всего, напишите их больше, и, следовательно, с большей вероятностью обнаружите ошибки перед отправкой кода 🙂
Кстати, это означает, что вам также необходимо «внедрение зависимостей»: ваш код должен принимать параметр типа интерфейса, и вы должны иметь возможность передавать либо фиктивный объект (для модульного тестирования), либо «реальный» Веб-сайт / база данных / датчик / что угодно (для реального использования).