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

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

Выполнение теста для нескольких, возможно, отказавших модулей, не будет модульным тестом.

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

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

Скажем, это для целей тестирования , Я издеваюсь над единицами DAL (создавая «пересмешников»).

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

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

Вывод: совершенно невозможно проводить" настоящие модульные тесты "

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

Серьезно, вот и все.

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

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

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

Сложный ...

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

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

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

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

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

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