Что не проверить, когда дело доходит до модульного тестирования?

Question

В каких частях написания юнит-тестов проекта практически или практически невозможно? Доступ к данным? FTP

Если есть ответ на этот вопрос, то охват 100% - это миф, не так ли?

Answer 1

Здесь Я нашел (через взломан что-то, что Майкл Фезерс говорит, что может быть ответом:

Он говорит,

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

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

Снова в той же статье он добавляет:

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

Answer 2

То, что 100% -ое покрытие - это миф, и это не значит, что 80% -ое покрытие бесполезно. Цель, конечно, на 100%, и между юнит-тестами и интеграционными тестами вы можете приблизиться к ней.

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

Answer 3

достижение 100% покрытия кода почти всегда расточительно. Об этом много ресурсов.

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

Answer 4

Целью является не 100% покрытие кода и не 80% покрытие кода. Простота написания модульного теста не означает, что вы должны его написать, а сложность написания модульных тестов не означает, что вам следует избегать усилий.

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

Оправдывает ли общая стоимость разработки, сопровождения и диагностики проблем, отмеченных тестом (включая ложные срабатывания), проблемы, которые улавливает конкретный тест?

Если проблема, с которой сталкивается тест, является «дорогой», тогда вы можете позволить себе попытаться выяснить, как ее протестировать, и поддерживать этот тест. Если проблема, с которой сталкивается тест, тривиальна, то написание (и поддержание!) Теста (даже при наличии изменений кода) лучше сделать тривиальным.

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

Answer 5

Что бы вы не тестировали? Все, что не могло сломаться.

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

Answer 6

Модульное тестирование GUI также сложно, хотя, я полагаю, не невозможно.

Answer 7

Доступ к данным возможен, потому что вы можете настроить тестовую базу данных.

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

Кроме того, 100% покрытия кода недостаточно само по себе.

Answer 8

В модульном тестировании вы не должны тестировать ничего, что не принадлежит вашему устройству; Тестирование юнитов в их контексте - это другое дело. Это простой ответ.

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

Это не значит, что вы не должны опускать то, что просто сложно проверить; Даже обработка исключений и проблемы параллелизма могут быть достаточно хорошо протестированы с помощью правильных инструментов.

Answer 9

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

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

Очень полезно проводить различие между юнит-тестами и интеграционными тестами. Юнит-тесты должны выполняться очень быстро. Должно быть легко выполнить все ваши юнит-тесты перед проверкой кода.

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

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

Answer 10

Все, что не является полностью детерминированным, является нет-нет для юнит-тестирования. Вы хотите, чтобы ваши модульные тесты ВСЕГДА проходили или терпели неудачу при одинаковых начальных условиях - если на это могут повлиять такие странности, как многопоточность, или случайная генерация данных, или время / даты, или внешние сервисы, то вам не следует включать их в свои модульные тесты , Время / даты - особенно неприятный случай. Обычно вы можете сконструировать код, чтобы иметь дату, с которой нужно было работать, с помощью кода и тестов, а не полагаться на функциональность в текущую дату и время.

Тем не менее, модульные тесты не должны быть единственным уровнем тестирования в вашем приложении. Достижение 100% покрытия модульным тестом часто является пустой тратой времени и быстро приносит убывающую прибыль.

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