Что определяет «изолированный» тест?

Question

У меня есть класс с именем Customer, и я хочу провести модульное тестирование этого класса и его открытого интерфейса.Чтобы иметь возможность модульного тестирования , я должен протестировать Customer в отрыве от его real зависимостей.Кроме Customer, у меня есть класс Monster, который я создал.

Мое приложение использует игровую среду, которая определяет Shape (представляет форму) и Vec2F (представляет векториспользуется для математики).Customer полагается (использует) на Shape и Vec2F.Он также использует Monster.

Теперь я должен смоделировать эти реальные зависимости, чтобы мои тесты были модульными, а не интеграционными.Однако, что определяет «реальные» зависимости?Как будто я понимаю, почему я высмеиваю мою собственную реализацию Monster, но Vec2F и Shape из используемой мной структуры кажутся такими фундаментальными структурами.

Answer 1

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

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

Следовательно, имитация должна выполняться только при наличии веской причины для симуляции.На это есть веские причины:

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

Например, вы (обычно) не высмеиваете стандартные библиотечные математические функции, такие как sin или cos, потому что у них нет ни одной из вышеупомянутых проблем.То же самое может иметь место, в вашем случае для Vec2F и Shape, но вам придется судить об этом самостоятельно.Приведенный выше список критериев должен вам помочь.

Answer 2

Тесты должны быть изолированы от других тестов.Для этого вам необходимо смоделировать любое глобальное состояние, используемое тестируемой системой.

Если тестируемая система не использует глобальное / общее состояние - ничего не поделать.
В идеальном мире, где настройка новой базы данных займет миллисекунды, вы можете создать новую базу данных для каждого теста (In-База данных памяти в EF Core).

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

Те зависимости, которые вы хотите высмеятьобеспечить более быструю обратную связь (юнит-тесты).

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

В вашем конкретном тестовом примере я ничего не высмеиваю, если только классы инфраструктуры не зависят от логики экрана рисования (зависит от API среды).