Тестирование: единицу против интеграции против других, в чем заключается необходимость разделения?

На вопрос Я тестовый модуль или интеграционное тестирование? Я ответил немного провокационно: пройди тест, и пусть другие люди проводят время с таксономией.

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

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

Мое мнение неверно? Существуют ли другие рабочие процессы, которые не подчеркивают это разделение (возможно, гибкие методы)? Каков ваш опыт по этому вопросу?

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

Ответ 1

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

Группы модульных тестов должны выполняться как можно быстрее и быть в состоянии запускать после каждой компиляции.

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

Если все тесты были сгруппированы вместе, я бы никогда не запускал никаких тестов до тех пор, пока не проведет проверку, что замедлит мои общие темпы развития.

Ответ 2

Мне пришлось бы согласиться с @Alex B в том, что вам нужно проводить различие между модульными тестами и интеграционными тестами при написании тестов, чтобы ваши единичные тесты выполнялись как можно быстрее и не имели больше зависимостей, чем требуется для проверки код под тестированием. Вы хотите, чтобы модульные тесты выполнялись очень часто, и чем больше "интеграции", тем меньше они будут выполняться.

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

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

Ответ 3

Определения из моего мира:

Unit test - проверить очевидные пути кода и обеспечить ожидаемые результаты.

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

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

Интеграционный тест - запустите его на типичной системной настройке и посмотрите, вызывает ли другое программное обеспечение конфликт с тестируемым.

Ответ 4

Конечно, ваше мнение неверно, по крайней мере, в отношении сложных продуктов.

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

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

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

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