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

Question

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

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

Answer 1

@ GarryShutler

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

http://maas -frensch.com / питер / 2007/08/29 / модульное тестирование, электронная почта, отправка-используя пружинный /

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

Answer 8

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

Answer 9

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

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

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

Answer 10

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

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