Что не протестировать когда дело доходит до Поблочного тестирования?

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

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

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

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

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

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

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

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

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

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

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

Что-либо вне этого - интеграционное тестирование.

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

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

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

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

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

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

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

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

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

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

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

очень полезно сделать различие между модульными тестами и интеграционными тестами. Модульные тесты должны работать очень быстро. Должно быть легко возможно выполнить все Ваши модульные тесты перед регистрацией в коде.

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

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

@GarryShutler

я на самом деле unittest электронная почта при помощи фальшивки smtp (Более мудрый) сервер. Удостоверяется Вы, код приложения корректен:

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

Что-то как этот могло, вероятно, быть сделано для других серверов. Иначе необходимо быть в состоянии дразнить API...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"Что не протестировать когда дело доходит до Поблочного тестирования?" * Бобы только с методами get и методами set. Обоснование: Обычно пустая трата времени, которая могла быть лучше потрачена, тестируя что-то еще.