Когда тест не является юнит-тестом?

Question

Я ищу такие правила, как:

Тест не является юнит-тестом, если:

• связывается с базой данных
• он не может работать параллельно с другими тестами
• использует "среду", такую ​​как реестр или файловую систему

Что еще там?

Answer 1

См. определение Майкла Перса

Тест не является модульным тестом, если:

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

Answer 2

Тест не является юнит-тестом, если он не тестирует юнит.

Серьезно, это все, что нужно.

Понятие «юнит» в модульном тестировании не является четко определенным, на самом деле, лучшее определение, которое я нашел до сих пор, на самом деле не является определением, потому что оно круговое: единица в модульном тесте является наименьшей возможная вещь, которую можно испытать изолированно.

Это дает вам две контрольные точки: это тестируется изолированно? И это самая маленькая вещь?

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

Answer 3

Он не имеет утверждений и не ожидает исключения

Answer 4

Тест не является модульным тестом, когда:

• он проверяет более чем одну вещь одновременно (то есть он проверяет, как две вещи работают вместе) - тогда это интеграционный тест

Контрольный список для хороших модульных тестов:

• они автоматизированы
• они повторяются
• они просты в реализации
• они остаются для будущего использования, однажды написанные
• ими может управлять любой
• они могут быть запущены нажатием кнопки
• они бегут быстро

Еще несколько лучших практик (без определенного порядка важности):

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

Это часть знаний, которые я извлек из книги Роя Ошерова - Искусство юнит-тестирования

Answer 5

Сложный ...

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

Но с другой стороны ... можем ли мы на 100% сказать правильно или неправильно ?? Не для того, чтобы стать философским, но - как и Майкл говорит в своем посте:

Тесты, которые делают эти вещи , не плохие. Часто их стоит написать , и они может быть записано в модульном тесте. Тем не менее, важно иметь возможность отделить их от истинных юнит-тестов так что мы можем сохранить набор тестов, которые мы можем бежать быстро, когда мы делаем меняется.

Так почему бы мне не написать модульный тест, который проверяет логику синтаксического анализа, например, файла xls, путем доступа к некоторому фиктивному файлу из файловой системы в моей тестовой папке (как MS-тесты позволяют с помощью DeploymentItem)?

Конечно, как уже упоминалось, мы должны отделять подобные тесты от других (возможно, в отдельном наборе тестов в JUnit). Но я думаю, что нужно также написать эти тесты, если он чувствует себя комфортно, имея их там ... ясно, тогда всегда снова вспоминая, что модульный тест должен просто проверить кусок в изоляции.

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

Answer 6

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

Answer 7

Запутанный вопрос.

Скажем, я должен запрограммировать некоторую бизнес-логику, и вся бизнес-логика должна получить данные через какую-то форму DAL.

Скажите, что в целях тестирования я издеваюсь над блоками DAL (создавая "пересмешников").

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

Конечно, общеизвестно, что "создание пересмешников для DAL" может сделать недействительным сам ваш тест на счет того, что пересмешник отклоняется в каком-то конкретном аспекте от DAL.

Вывод: невозможно провести «подлинные юнит-тесты» на бизнес-модулях, которые каким-либо образом зависят от любого типа DAL, вопросительный знак?

Corrolary: единственное, что может быть («искренне»!) Проверено модулем, это сам DAL, знак вопроса?

Подтверждение соответствия: с учетом того, что «DAL» обычно является либо ORM, либо самим DML некоторых СУБД, и учитывая, что эти продукты обычно покупаются как «проверенная технология», какова дополнительная ценность выполнения любых модульные тесты, что так, вопросительный знак?

Answer 8

После того, как тест закончен, или нет, возникает следующий вопрос: является ли хорошим модульным тестом ?