В зависимости от того, куда вы смотрите, вы получите несколько разные ответы. Я много читал на эту тему, и вот моя перегонка; опять же, они слегка шерстистые, и другие могут не согласиться.
Модульные тесты
Тестирует наименьшую единицу функциональности, обычно это метод / функцию (например, если дан класс с определенным состоянием, вызов метода x в классе должен вызвать y). Модульные тесты должны быть сосредоточены на одной конкретной функции (например, вызов метода pop, когда стек пуст), должен генерировать InvalidOperationException). Все, к чему это касается, должно быть сделано в памяти; это означает, что тестовый код и тестируемый код не должны:
- Вызвать (нетривиальных) соавторов
- Доступ к сети
- Хит базы данных
- Используйте файловую систему
- Раскручивать нить
- и т.п.
Любые виды зависимостей, которые медленно / трудно понять / инициализировать / манипулировать, должны быть заглушены / смоделированы / отбелены с использованием соответствующих методов, чтобы вы могли сосредоточиться на том, что делает модуль кода, а не на том, что делают его зависимости.
Короче говоря, модульные тесты настолько просты, насколько это возможно, легко отлаживаются, надежны (благодаря уменьшению внешних факторов), быстро выполняются и помогают доказать, что наименьшие строительные блоки вашей программы функционируют так, как задумано, до того, как они собраны вместе. Предостережение заключается в том, что, хотя вы можете доказать, что они прекрасно работают в изоляции, блоки кода могут взорваться при объединении, что приводит нас к ...
Интеграционные тесты
Интеграционные тесты основаны на модульных тестах, комбинируя блоки кода и проверяя, что получающаяся комбинация функционирует правильно. Это может быть как внутренняя часть одной системы, так и объединение нескольких систем, чтобы сделать что-то полезное. Кроме того, еще одна вещь, которая отличает интеграционные тесты от юнит-тестов, это среда. Интеграционные тесты могут и будут использовать потоки, обращаться к базе данных или делать все, что требуется, чтобы гарантировать, что весь код и различные изменения среды будут работать правильно.
Если вы создали некоторый код сериализации и проверили его внутренности, не касаясь диска, как вы узнаете, что он будет работать при загрузке и сохранении на диск? Может быть, вы забыли очистить и утилизировать файловые потоки. Возможно, ваши права доступа к файлам неверны, и вы проверили внутренности, используемые в потоках памяти. Единственный способ узнать наверняка - это проверить его «по-настоящему», используя среду, наиболее близкую к производственной.
Основным преимуществом является то, что они найдут ошибки, которые не могут пройти модульные тесты, такие как ошибки проводки (например, экземпляр класса A неожиданно получает нулевой экземпляр B) и ошибки среды (это нормально работает на моей однопроцессорной машине, но мой 4-ядерный компьютер коллеги не может пройти тесты). Основным недостатком является то, что интеграционные тесты затрагивают больше кода, менее надежны, сбои труднее диагностировать и труднее поддерживать тесты.
Кроме того, интеграционные тесты не обязательно доказывают, что полная функция работает. Пользователь может не заботиться о внутренних деталях моих программ, но я делаю!
Функциональные тесты
Функциональные тесты проверяют правильность конкретной функции, сравнивая результаты для данного ввода со спецификацией. Функциональные тесты не касаются промежуточных результатов или побочных эффектов, а только результата (их не волнует, что после выполнения x объект y имеет состояние z). Они написаны для проверки части спецификации, такой как «вызов функции Square (x) с аргументом 2 возвращает 4».
Приемочные испытания
Приемочные испытания, похоже, делятся на два типа:
Стандартное приемочное тестирование включает в себя выполнение тестов на всей системе (например, с использованием вашей веб-страницы через веб-браузер), чтобы увидеть, удовлетворяет ли функциональность приложения спецификации. Например, «нажатие на значок масштабирования должно увеличить вид документа на 25%». Нет никакого реального континуума результатов, только результат успеха или неудачи.
Преимущество заключается в том, что тесты описаны на простом английском языке и обеспечивают полную функциональность программного обеспечения. Недостатком является то, что вы переместились на другой уровень вверх по пирамиде тестирования. Приемочные тесты затрагивают горы кода, поэтому отследить сбой может быть сложно.
Кроме того, в гибкой разработке программного обеспечения приемочное тестирование пользователя включает в себя создание тестов для отражения пользовательских историй, созданных заказчиком программного обеспечения во время разработки. Если тесты пройдены, это означает, что программное обеспечение должно соответствовать требованиям заказчика, и истории можно считать завершенными. Пакет приемочных тестов - это в основном исполняемая спецификация, написанная на языке, специфичном для предметной области, который описывает тесты на языке, используемом пользователями системы.
Вывод
Они все дополняют друг друга. Иногда выгодно сосредоточиться на одном типе или полностью отказаться от них. Основное отличие для меня состоит в том, что некоторые тесты смотрят на вещи с точки зрения программиста, тогда как другие используют ориентацию на клиента / конечного пользователя.