Тестирование серверной части веб-приложения является важной частью процесса разработки и любого постоянного мониторинга. Также см. тестирование внешнего интерфейса .
Разработка через тестирование
При разработке через тестирование (TDD) требования к приложению переводятся в тестовые сценарии до того, как приложение будет полностью реализовано. Во время разработки эти тесты сначала пишутся и последовательно реализуются по мере сборки приложения. Четкие требования (т. е. тестовые примеры) гарантируют, что конечный код будет хорошо структурирован, будет соответствовать всем требованиям и будет корректным, что особенно важно на ранних этапах разработки.
Непрерывная интеграция и автоматизированное тестирование
Тестирование непрерывной интеграции (CI) автоматически запускает тесты на предмет любых изменений кода, например, во время проверки кода или при объединении кода в ваш репозиторий кода. Автоматизированные тесты повышают общее качество и уверенность в представленном коде за счет снижения рисков сбоев или регрессий во время разработки. Рекомендуется настроить систему автоматического тестирования для вашей среды, чтобы обеспечить работоспособность вашего приложения. Используйте систему, поддерживаемую вашей архитектурой, платформой и языком и легко интегрированную в ваш конвейер разработки; например, используйте GitHub Actions для рабочего процесса CI или собственный конвейер CI, встроенный в облако и настроенный для вашей конфигурации.
Узнайте больше о принципах автоматического тестирования и о том, как улучшить ваши тесты. Узнайте больше о непрерывном интеграционном тестировании и лучших методах внедрения, настройки и измерения успеха.
В качестве следующего шага рассмотрите автоматизированный конвейер непрерывной доставки (CD) для автоматического развертывания изменений и обновлений в вашем приложении.
Модульное тестирование
Модульное тестирование относится к изолированному тестированию небольших, автономных частей кода. Используйте среду модульного тестирования, рекомендованную и популярную для вашего внутреннего языка или платформы. Например, для монолитного приложения на основе Java используйте JUnit, а для бессерверного приложения на основе JavaScript (включая Dart или TypeScript) используйте платформу, созданную для тестирования Javascript, например Jest .
Большинство современных бэкэнд-фреймворков имеют выделенные ресурсы для тестирования. Рассмотрите возможность интеграции этих функций в ваш конвейер CI для автоматизации тестирования. Убедитесь, что ваши модульные тесты обеспечивают хорошее покрытие кода вашего приложения. Большинство платформ тестирования предоставляют функции для анализа и составления отчетов о покрытии тестами, а также позволяют интегрировать их в конвейер сборки.
Интеграционное тестирование
Интеграционное тестирование означает совместное тестирование более крупных модулей или частей вашего приложения. По сравнению с модульным тестированием (которое фокусируется на отдельных частях кода), интеграционное тестирование фокусируется на интеграции отдельных частей вашей архитектуры. Это также может включать сквозные потоки, охватывающие несколько шагов и модулей приложения.
Интеграционные тесты могут охватывать различные модули вашего приложения, которым может потребоваться взаимодействие с внешними сервисами, такими как хранилище данных, файловые системы или платежи. Рассмотрите возможность структурирования вашего приложения для поддержки абстракций для этих сервисов посредством внедрения зависимостей или аналогичных функций, предоставляемых вашей серверной платформой.
Поведенческое и функциональное тестирование
Подходя к серверной части (или отдельным модулям или компонентам) как к непрозрачной коробке, функциональное тестирование фокусируется на входных и выходных данных системы. Хотя поведенческое тестирование может быть более распространенным для внешнего интерфейса, оно также играет жизненно важную роль в подтверждении сквозной целостности внутренней системы. Эти типы тестов подтверждают, что система реагирует и ведет себя ожидаемым образом на различные входные данные.
Регрессионное тестирование
Регрессионное тестирование — это тесты, которые подтверждают, что приложение по-прежнему ведет себя так, как ожидалось. Успешно завершенные ранее тесты повторяются для любых новых изменений, чтобы гарантировать, что изменения не привели к повторному возникновению предыдущих проблем. По мере исправления ошибок в приложении следует добавлять модульные или интеграционные тесты, чтобы гарантировать, что ошибка не повторится. Регрессионные тесты должны быть интегрированы в обычный конвейер тестирования и сборки.
Дымовое тестирование
Дымовое тестирование , также называемое проверочным тестированием сборки, фокусируется на проверке наиболее важных функций вашего серверного приложения. Выходя за рамки интеграционного тестирования, которое абстрагирует некоторые функции и внешние зависимости, дымовое тестирование охватывает критические случаи использования вашего приложения. Дымовое тестирование может служить дополнительным уровнем проверки перед тем, как приложение будет переведено в промежуточную среду, чтобы обеспечить точное поведение. Дымовые тесты могут состоять из автоматизированных модульных тестов или ручных функциональных тестов, проводимых командой контроля качества.
Производственная и промежуточная среда
Промежуточная среда — это копия вашей производственной среды, помещенная в «песочницу» для облегчения тестирования. Специальное развертывание снижает риск возникновения проблем в производственной среде и упрощает контроль качества. Промежуточная среда позволяет тестировать систему, близкую к реальной производственной среде.
Создание копии производственной среды «один к одному» может оказаться невозможным из-за таких факторов, как стоимость или сложность серверной архитектуры. Подумайте, какие части серверной части являются наиболее важными, и оптимизируйте их для промежуточной среды.
Тестирование данных, используемых в производстве, дает большое преимущество для проверки того, как приложение ведет себя с реальными данными. Обязательно учтите последствия конфиденциальности и потребности в хранении данных для такой промежуточной среды и тщательно спроектируйте данные, используемые вашей серверной системой. Доступ к такой среде должен строго контролироваться, особенно если используются производственные данные.
Учитывайте масштаб вашей системы и то, подходит ли стоячая среда для вашего приложения. Подвижные промежуточные среды, которые можно автоматически развертывать с помощью системы непрерывной доставки, также предлагают дополнительные возможности для тестирования ежедневных или еженедельных сборок и дополнительной проверки перед выпуском.
Другой подход заключается в том, чтобы в большей степени полагаться на непрерывные интеграционные тесты и автоматизированные системы, а не на полностью развернутую промежуточную среду. Учитывайте рабочий процесс вашей команды, работоспособность системы, покрытие кода и технические требования.