Если мы тестируем функцию B, тестируя функцию C, которая вызывает эту функцию B, т. Е. Пишем тестовую программу для тестирования функции C, которая вызывает эту функцию B, метод теста все еще называется модульным тестом или что-то еще?
Когда предпочтительнее проводить косвенное тестирование функции, которая вызывает целевую функцию, и когда предпочтительнее тестировать функцию напрямую?
Ответы:
Популярное определение модульного теста - это определение ISTQB:
Модульный тест - это самая маленькая тестируемая часть приложения, такая как функции, классы, процедуры, интерфейсы. Модульное тестирование - это метод, с помощью которого отдельные блоки исходного кода тестируются, чтобы определить, пригодны ли они для использования.
Согласно этому определению:
Теперь может быть разница между намерением и областью тестирования. Если вы пишете тестовую программу для B с использованием C, это все еще является модульным тестом для C, потому что все, что вы можете сделать, это предоставить входные данные для C и проверить на основе выходных данных, был ли B правильным. Просто вы выводите, что B работает, потому что C работает.
Также есть определение интеграционного теста :
Тестирование проводится для выявления дефектов в интерфейсах и взаимодействиях между интегрированными компонентами или системами.
Обычное определение программных компонентов подразумевает, что оно является независимым и может быть развернуто самостоятельно. Здесь B и C не являются независимыми компонентами, поэтому у нас нет интеграционного теста.
Это очень сильно зависит от того, что вы считаете единицей. Если Cэто так просто, что тестировать его отдельно не имеет смысла, тогда ваш тест является модульным тестом.
Гораздо важнее, чтобы ваш набор модульных тестов для конкретного модуля имел близкое к 100% покрытие строк и тестировал все практически ожидаемые пути кода.
Да, мы все еще называем это юнит-тестом, если функции вызывают другие функции.
Модульные тесты должны проверять публичное поведение класса, а не частные реализации. Как предполагает это тестирование Google на туалетной статье .
Если вы следуете правилам Чистого кода, тогда ваши функции не должны быть длиннее 4 строк кода. Это делает невозможным не тестировать другую приватную функцию с вашими юнит-тестами.
Почему бы вам не протестировать большинство закрытых функций отдельно? Потому что рефакторинг заставит вас обновлять все свои юнит-тесты реализации. Это будет разочаровывать, если у вас их много, в то время как публичное поведение не должно меняться во время рефакторинга, и, следовательно, тест не должен обновляться. Вы должны быть в состоянии проверить рядовых с их публичным родителем. Иногда это может стоить проверить сложные рядовые, но интересно, должны ли они быть отдельным классом самостоятельно?
Интеграционный тест :
Теперь, если функция является частью другого класса, она отличается. Тогда мы бы назвали это компонентным тестированием или интеграционным тестированием. Вы интегрируете несколько классов и проводите тестирование против них. Функция B будет зависеть от функции C. Чтобы выполнить модульное тестирование функции B, вы можете использовать внедрение зависимостей, чтобы изолировать функцию, которую вы тестируете, теперь это снова будет модульный тест.