Когда тест не является модульным тестом?

Ответ 1

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

Тест не является unit test, если:

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

Ответ 2

Тест не является unit test, если он не тестирует устройство.

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

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

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

Ответ 3

У него нет утверждений, и он не ожидает, что будет выбрано исключение.

Ответ 4

Трудный...

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

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

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

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

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

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

Ответ 5

Тест не является Unit Test, если:

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

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

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

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

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

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

Ответ 6

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

Ответ 7

Сложный вопрос.

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

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

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

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

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

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

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

Ответ 8

После того, как тест будет unit test или нет, будет задан следующий вопрос: good unit test?