Тестирование модулей и тестирование интеграции в веб-разработке

Question

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

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

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

2. Довод

2,1 Нет Алгоритмы

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

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

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

2,2 Стоимость

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

3. Интеграция Test

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

3,1 тест интеграции говорит «что-то сломалось», но не говорит, где

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

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

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

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

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

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

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

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

Answer 1

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

Давайте пройдемся по вашим пунктам:

Нет Алгоритмы (но что вы имеете в виду несколько):

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

Стоимость

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

Тест Интеграция

тест, который тоже!

тест интеграции говорит «что-то сломалось», но не говорит, где

Мне очень жаль, но я не понимаю это.

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

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

Я нахожу this быть очень хорошая цитата о юнит-тестах

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

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

Редактировать Сообщества вика говорит, что это о тестировании интеграции:

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

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

Answer 2

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

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

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

Answer 3

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

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

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

• теста блок важен, блок проверяемого «ЛИЭС» (Auth, Платежная служба Абстракция и т.д.)
• тестирования блока модели, предполагающая у вас есть, где это возможно (и это действительно должно быть возможно!)
• тест Интеграция важных конечных точек приложения (полностью зависит от приложения)

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

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