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

Ответ 1

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

Он говорит:

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

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

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

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

Ответ 2

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

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

Ответ 3

достижение 100% -ного охвата кода почти всегда расточительно. На этом есть много ресурсов.

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

Кроме того, 100% -ный охват кода недостаточен сам по себе.

Ответ 7

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

Ответ 8

@GarryShutler

На самом деле я отправляю адрес электронной почты с помощью фальшивого SMTP-сервера (Wiser). Убедитесь, что код приложения верен:

http://maas-frensch.com/peter/2007/08/29/unittesting-e-mail-sending-using-spring/

Возможно, что-то подобное может быть сделано для других серверов. В противном случае вы должны будете фальсифицировать API...

BTW: 100% охват - это только начало... просто означает, что весь код на самом деле bean выполнен один раз.... ничего о случаях края и т.д.

Ответ 9

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

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

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

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

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

Ответ 10

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

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

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

Ответ 11

"Что не следует проверять, когда дело доходит до Unit Testing?" * Beans с помощью только геттеров и сеттеров. Рассуждение: обычно пустая трата времени, которая может быть лучше потрачена на тестирование чего-то другого.

Ответ 12

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

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

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

Ответ 13

Pex - автоматическое тестирование Whitebox для .NET пытается достичь 100% -ного охвата

Ответ 14

Все, что требует очень большой и сложной настройки. Конечно, вы можете протестировать ftp (клиент), но тогда вам нужно настроить ftp-сервер. Для unit test вам нужна воспроизводимая тестовая установка. Если вы не можете его предоставить, вы не можете проверить его.

Ответ 15

Вы можете протестировать их, но они не будут модульными тестами. Unit test - это нечто, что не пересекает границы, например, пересечение провода, попадание в базу данных, запуск/взаимодействие с третьей стороной, обращение к непроверенной/устаревшей кодовой базе и т.д.

Все, что выходит за рамки этого, является интеграционным тестированием.

Очевидный ответ на вопрос в названии: вы не должны Unit test внутренности вашего API, вы не должны полагаться на поведение другого человека, вы не должны тестировать что-либо, за что вы несете ответственность.

Остальное должно быть достаточно, чтобы вы могли писать свой код внутри него, а не больше, не меньше.

Ответ 16

Я не согласен с ответом quamrana относительно не тестирования стороннего кода. Это идеальное использование unit test. Что делать, если ошибки появляются в новой версии библиотеки? В идеале, когда выпущена сторонняя библиотека новой версии, вы запускаете модульные тесты, которые представляют ожидаемое поведение этой библиотеки, чтобы проверить, что она по-прежнему работает должным образом.

Ответ 17

Кроме того, некоторые ответы могут быть извлечены из других вопросов (Что делает хороший unit test?)...

Ответ 18

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

Ответ 19

FTP, SMTP, I/O в целом должны быть протестированы с использованием интерфейса. Интерфейс должен быть реализован с помощью адаптера (для реального кода) и макета для unit test.

Нет unit test должен использовать реальный внешний ресурс (FTP-сервер и т.д.)

Ответ 20

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

Ответ 21

FTP, электронная почта и т.д. вы можете протестировать с помощью эмуляции сервера. Это трудно, но возможно.

Невозможно выполнить проверку ошибок. В каждом коде есть обработка ошибок, которая никогда не может произойти. Например, в Java должно быть много исключений, поскольку это часть интерфейса. Но используемый экземпляр никогда не бросит его. Или вариант по умолчанию для коммутатора, если для всех возможных случаев существует блок case.

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

Ответ 22

Основная причина для кода unit test в первую очередь заключается в проверке дизайна вашего кода. Это позволяет получить 100% -ный охват кода, но не без использования макетных объектов или какой-либо формы изоляции или инъекции зависимостей.

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

Ответ 23

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

Исчерпывающее тестирование таких вещей, как подача форм, доступ к базе данных, доступ к FTP и т.д. на очень подробном уровне, часто является пустой тратой времени; если написанное программное обеспечение не нуждается в очень высоком уровне надежности (99,999%), то тестирование модулей слишком много, может быть излишним и раковиной в реальном времени.