Поблочное тестирование — фундаментальная цель?
Меня и моих коллег имел определенное разногласие вчера вечером о поблочном тестировании в нашем приложении PHP/MySQL. Половина из нас утверждала это, когда поблочное тестирование функция в классе, необходимо дразнить все за пределами того класса и его родителей. Другая половина из нас утверждала, что Вы не ДОЛЖНЫ дразнить ничего, что является прямой зависимостью класса также.
Определенным примером был наш механизм входа, который произошел через статический класс Входа, и у нас было много Входов:: журнал () звонит в различные местоположения всюду по нашему приложению. Первая половина из нас сказала, что Регистрирующийся механизм должен фальсифицироваться (дразнивший), потому что это было бы протестировано в Регистрирующихся модульных тестах. Вторая половина из нас утверждала, что мы должны включать исходный класс Входа в наш модульный тест так, чтобы, если мы вносим изменение в наш интерфейс входа, мы смогли видеть, создает ли это проблемы в других частях приложения из-за отказа обновить интерфейс вызова.
Таким образом, я предполагаю, что фундаментальный вопрос - модульные тесты служат, чтобы протестировать функциональность единого блока в закрытой среде или показать последствия изменений в едином блоке в большей среде? Если это - один из них, как Вы выполняете другой?
4 ответа
Юнит-тестирование похоже на тестирование отдельного компонента в электронном устройстве.
Если вы хотите протестировать один транзистор в гитарном усилителе, вы не подключаете гитару, не увеличиваете громкость и не проверяете издаваемые звуки. Это было бы глупо. Чтобы проверить транзистор, вы подключаете оборудование к выводам этого транзистора и измеряете только его входы и выходы.
В какой-то момент вы проверяете все устройство (гитара шумит и т.д.), но это совсем другое дело, чем проверка одного транзистора.
Слова дают некоторые подсказки относительно ответа:
unit означает 1 : вы пытаетесь проверить одну вещь. Вы можете имитировать зависимости, такие как структура ведения журнала, когда это не является основной задачей ваших тестов. То, как тестируемый модуль взаимодействует со своими зависимостями, часто является частью тестового примера, и имитация делает это намного проще.
интеграция означает объединение нескольких вещей: вы пытаетесь объединить несколько вещей вместе в тесте в целом. Мокинг играет меньшую роль, но он все же может быть полезен для эмуляции зависимостей, которые было бы сложно настроить в тестовом сценарии.
Я бы сказал, что аргумент в пользу того, чтобы не высмеивать систему журналирования в модульных тестах, чтобы увидеть, сломают ли изменения что-либо, довольно слабый. Если что-то сломано в системе журналирования, то это должно быть обнаружено неудачным модульным тестом для системы журналирования.
Сохранение простоты, ясности и целенаправленности модульных тестов - хорошее практическое правило. Юу нужна эта простота при расширении диапазона тестов. Интеграционные тесты могут быстро стать сложными, особенно при использовании их в качестве замены отсутствующих модульных тестов - это похоже на «тестирование на расстоянии», и чем дальше вы удаляетесь от компонента, тем сложнее тестировать и диагностировать сбои. Тестирование удаленной зависимости с помощью модульного теста подобно тому, как человек пытается управлять ТВ-пультом с другой стороны комнаты с помощью удочки.
@David, я вижу, что модульное тестирование для вас делает работу, которую должно делать.
Вы размышляете над дизайном своего программного обеспечения.
Судя по тому, как вы задаете свой вопрос о сравнении закрытой среды и открытой среды, я могу предположить, что вы стоите на пороге того, чтобы ответить на вопрос о модульном тестировании на основе состояния и поведения для вашего кода.
Не существует жесткого правила, когда использовать реальный объект или макет для модульного тестирования. ТОЛЬКО РУКОВОДЯЩИЕ ПРИНЦИПЫ! Проблема модульного тестирования с реальным объектом Logging заключается в том, что тесты для этого объекта будут не только в модульных тестах для регистратора, но и в модульных тестах для объектов, использующих регистратор.
Итак, если у вас есть 20 объектов, которые используют регистратор, и при изменении интерфейса регистратора будет как минимум 21 неудачный тест. При рефакторинге это может быть довольно сложной задачей. Но с другой стороны, если вы не используете класс регистратора в 20 модульных тестах объектов и измените интерфейс регистратора, у вас будет только один неудачный тест и 20 других модульных тестов, которые станут зелеными, даже если они не пройдут в производственной среде.
Единственное, что я могу вам дать, это то, что у вас нет нужных абстракций. Вы можете найти SOLID . Это должны быть руководящие принципы.
Помните, что всякий раз, когда возникают вопросы, подобные вашим, это код обратной связи. Примите во внимание эту обратную связь. Позже это избавит вас от боли.
Вы и ваши коллеги наткнулись на разницу между модульными и интеграционными тестами. Для первых нужно все высмеивать, для вторых - не высмеивать зависимости.
Конечно, то, где вы проводите черту для детализации, тоже в некотором роде субъективно - но на самом тонком уровне детализации для модульного тестирования вы не должны беспокоиться ни о чем за пределами конкретного предмета каждого теста.