Вы больше концентрируетесь на модульных, интеграционных или приемочных тестах?

Question

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

Мой вопрос: когда вы работаете вне Agile-среды, сколько усилий вы вкладываете в юнит-тесты, интеграционные и приемочные тесты и из чего вы видите наибольшую ценность?

Answer 1

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

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

Многие будут утверждать, что модульные тесты ориентированы на разработчиков, они будут правильными. Тем не менее, отсутствие модульных тестов само по себе является индикатором, особенно если тот, кто проводит приемочные тесты, оказывается разработчиком:)

Edit:

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

Answer 2

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

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

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

Так что, ИМХО, оба абсолютно необходимы, и с точки зрения рентабельности инвестиций было бы плохой идеей исключить любую из них.

Answer 3

Очень часто ответ на этот вопрос идет до крайности. Как будто у вас должно быть покрытие почти на 100%, или юнит-тесты глупы ...

Я считаю, что вы должны найти баланс.

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

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

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

Answer 4

Я думаю, вы не можете смешать это. Каждый из описанных вами тестов имеет свою цель.

Модульный тест предназначен для разработчиков. Они пишут модульное тестирование до или параллельно с реализацией модуля, чтобы убедиться, что он работает или все интерфейсы и требования выполнены.

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

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