Определение модульного теста - внешние и объемные зависимости

Question

У меня путаница при пересмотре определения модульного теста.
Я думаю, что модульные тесты связаны с имитацией внешних зависимостей, объем может быть большим, как ИТ-тест (более одного класса).Таким образом, я могу тестировать в своем полном потоке UT, и это может помочь мне быстро обнаруживать ошибки (я не использую Spring, я не использую внешние зависимости), я хочу быстро поймать ошибку, потому что если я 'Я занимаюсь рефакторингом, я хочу запускать свои тесты каждые несколько минут, чтобы увидеть, что-то не работает, поэтому мне нужно, чтобы мои тесты выполнялись быстро.(Вот почему я хочу запускать только UT, а не IT-тесты.)

Похоже, что в индустрии, когда речь идет о UT, UT должно быть small (scope), а также mockвнешние зависимости.Я не думаю, что это хороший способ мышления, потому что это означает, что мой UT может пропустить ошибки, которые выявляет IT, а это означает, что запуск только UT каждые несколько минут не достаточно хорош, и я должен выполнять IT-тесты, которые намного медленнее, чтоэто нехорошо для меня, потому что процесс рефакторинга займет у меня намного больше времени.

Так что я что-то упустил?Почему бы не написать UT, который тестирует завершенные потоки так же, как ИТ, но с насмешкой над внешними зависимостями?Спасибо

Answer 1

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

Это определение устанавливает нижнюю границу объема модульного тестирования, а именно, начиная с самых маленьких программ.Для верхней границы это оставляет степень свободы.Иногда люди пытаются также разграничить верхнюю границу, придумав определения термина «единица измерения».Но мне все равно, что такое юнит.Вместо этого я установил ограничение на основе вопроса о том, насколько большим может быть тестируемый программный компонент, чтобы методы модульного тестирования все еще могли применяться разумно.

Например: одна функция, скажем, 15 строккода будет подвергаться модульному тестированию.Но что, если я произвожу рефакторинг своего кода так, чтобы из функции были извлечены две вспомогательные функции?В соответствии с определением я теперь мог также применить модульное тестирование к вспомогательным функциям.Но, если у меня уже был отличный набор юнит-тестов, они все равно должны работать с интерфейсом исходной функции.Таким образом, я мог бы сохранить свои тесты и игнорировать измененную внутреннюю структуру - и это все равно будет модульное тестирование.

Другой пример: в C ++ контейнерные классы объединяются со связанными классами итераторов.Контейнерный класс и его соответствующие классы итераторов тесно связаны.Тестирование этих классов вместе с методами юнит-тестирования будет хорошо работать во многих случаях.При тестировании итератора вы обычно не изолируете его от класса контейнера, а скорее тестируете оба вместе - и я по-прежнему считаю это модульным тестированием.

Сводная часть 1: КакПока применение методов модульного тестирования имеет смысл, вы также можете применять его к наборам тесно связанных функций и даже тесно связанных классов.

Снова взглянув на приведенное выше определение, в нем упоминается изоляция.Обратите внимание, однако, что изоляция здесь используется для классификации типов ошибок, которые могут быть обнаружены: модульное тестирование для выявления ошибок, которые можно найти в изолированном программном обеспечении.В нем не говорится, что вы на самом деле должны изолировать код во время тестирования.Другими словами, вам не обязательно издеваться над зависимостями.

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

Вы бы, например, делали насмешки, если бы зависели откомпонент (DOC) вызывает недетерминированное поведение (случайность, время, ...).Однако с помощью mock вы не можете найти тех ошибок, которые связаны с неправильными представлениями о том, как должно работать взаимодействие тестируемой функции с DOC: так как вы реализуете mocks, вы реализуете их на основе ваших потенциальных заблуждений.Это не недостаток модульного тестирования: это просто причина, по которой в дополнение к модульному тестированию вам также необходимы интеграция и тестирование системы.

Сводная часть 2: Модульное тестированиене обязательно насмешливый.Речь идет о поиске особых ошибок: таких, которые вы могли бы найти , если код был изолирован.Это исключает все другие ошибки (особенно те, которые вы можете найти только в интегрированном программном обеспечении) из области модульного тестирования.

Answer 2

Обычно модульный тест - это тест, который охватывает один метод одного класса.

В объектно-ориентированном программировании единица часто представляет собой целый интерфейс, такой как класс, но может быть отдельным методом (https://en.wikipedia.org/wiki/Unit_testing)

Одно отличие состоит в том, что люди считаютбыть объектами. Объектно-ориентированный дизайн имеет тенденцию рассматривать класс как единицу, процедурный или функциональный подходы могут рассматривать одну функцию как единое целое. Но на самом деле это ситуативная вещь - команда решает, что имеет смысл быть единицей дляв целях понимания системы и ее тестирования. Хотя я начинаю с представления о том, что модуль является классом, я часто беру кучу тесно связанных классов и отношусь к ним как к одному модулю. Редко я могу взять подмножество методов вкласс как единое целое. Однако вы определяете, что это на самом деле не имеет значения (https://martinfowler.com/bliki/UnitTest.html)

Обычно у вас есть модульные тесты, которые охватывают небольшие фрагменты кода, и интеграционные тесты, которые тестируют интеграцию между несколькими классами / модулямиИ вы запускаете модульные тесты гораздо чаще, чем ИТ-тесты.

Цельиз небольших модульных тестов, чтобы найти кусок кода, который вызвал ошибку как можно точнее.Если ваш It-тест, использующий несколько классов, не пройден, вам нужно проверить все эти классы по одному, чтобы найти проблему.Но если ваш модульный тест, охватывающий один метод одного класса, не пройден, вы точно знаете, в чем проблема.