Unit Test против теста интеграции в веб-разработке

Я хотел бы спросить об использовании Unit Testing в веб-разработке. Идея Unit Testing отличная, но действительно ли она приносит пользу в контексте веб-приложения? Вторая часть моего вопроса касается TDD. Если вы создаете интеграционный тест, прежде чем фактический код может называться "Test Driven Development"?

1. Предположения

По определению Unit Test должен проверять код только на одном сервисном слое. Если тест тестирует код на нескольких уровнях, у нас есть тест интеграции.

2. Аргумент

2.1 Нет алгоритмов

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

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

Если вы хотите построить Unit Test для каждого класса в веб-приложении, вы будете тестировать (в большинстве случаев): заполнять массивы, конкатенации строк и собственные функции языков.

2.2 Стоимость

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

3. Тест интеграции

Если веб-разработка связана с интеграцией, почему бы не протестировать ее? Существует несколько аргументов счетчика.

3.1. Тест интеграции говорит, что "что-то сломано", но не говорит, где

Это действительно сводится к следующему: сколько времени требуется, чтобы найти ошибку, когда тест интеграции завершился неудачно по сравнению с временем, необходимым для создания кода "UnitTestable" и более сложным (я думаю, это субъективно)? По моему опыту, никогда не было времени найти источник проблемы.

3.2 Вы можете запустить Unit Test в любой среде, это трудно сделать с тестом интеграции

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

3.3 Интеграция Тесты трудно поддерживать

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

4. Создайте хорошие модульные тесты!

Весь аргумент может быть атакован с помощью "Если вы создаете право Unit Test, то у вас нет никаких проблем". Не может ли быть одинаковым с интеграционными тестами? Если проще создать интеграционный тест, почему бы не придерживаться его и не сделать это правильно?

Не поймите меня неправильно, я не против Unit Test. Это идеальная идея, и я рекомендую всем. Я пытаюсь понять: действительно ли это подходит для веб-разработки? Я хотел бы услышать ваши мнения и опыт.

Ответ 1

Это чертовски хороший вопрос и тот, который разработчики должны задавать себе.

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

При принятии решения о ваших стратегиях тестирования точки, которые вы подняли, очень верны. В коммерческом мире стоимость (с точки зрения времени), вероятно, является самым важным фактором. Я всегда придерживаюсь некоторых простых правил, чтобы мои стратегии тестирования были реалистичными.

Unit test важные, единичные тестируемые "libs" (Auth, Billing, сервисные абстракции и т.д.).
Unit test, если у вас есть, где возможно (и это действительно должно быть возможно!)
Интеграция проверит важные конечные точки вашего приложения (полностью зависит от приложения)

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

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

Ответ 2

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

Пропустите свои очки:

Нет алгоритмов (но то, что вы имеете в виду, немного):

Хорошо, как указано в комментариях, это зависит от приложения. Это фактически не имеет никакого отношения к TDD. Наличие нескольких алгоритмов не является аргументом, чтобы не тестировать их. У вас может быть несколько разных случаев с множеством разных состояний. Не было бы хорошо знать, что они работают по назначению?

Стоимость

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

Интеграционный тест

Проверьте это тоже!

Тест интеграции говорит "что-то сломано", но не говорит, где

Извините, но я не понимаю этого.

Трудно поддерживать

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

Я нахожу этот, чтобы быть очень приятной цитатой об модульных тестах

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

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

Edit Вики сообщества сообщают об интеграционном тестировании:

В тесте интеграции все модули ввода - это модули, которые уже прошли тестирование. Эти модули сгруппированы в более крупные агрегаты и интеграционные тесты (определенные в плане тестирования интеграции) применяются к этим агрегатам. После успешного теста интеграции, интегрированная система готова к тестированию системы.

Итак, на самом деле мое понимание того, что integration testing было ошибочным с самого начала, но я не думаю, что мой ответ слишком далеко, за исключением последнего абзаца.

Ответ 3

Тест интеграции требует больше времени для выполнения по сравнению с unit test.

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

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