В этой статье мы собираемся изучить интеграционное тестирование клиента Feign .
Мы создадим базовый клиент Open Feign, для которого напишем простой интеграционный тест с помощью WireMock .
После этого мы добавим конфигурацию ленты в наш клиент, а также создадим для нее интеграционный тест. И, наконец, мы настроим тестовый контейнер Eureka и протестируем эту настройку , чтобы убедиться, что вся наша конфигурация работает должным образом. ** ** ****
Гибридное определение bean - компонентов в приложении Spring Boot включает в себя как конфигурацию на основе аннотаций, так и конфигурацию на основе XML . В этой среде мы можем захотеть использовать конфигурацию на основе XML в тестовых классах . Однако иногда в этой ситуации мы можем столкнуться с ошибкой загрузки контекста приложения « Не удалось загрузить ApplicationContext ». Эта ошибка появляется в тестовых классах, потому что контекст приложения не загружается в тестовый контекст.
В этом руководстве мы обсудим , как интегрировать контекст приложения XML в тестирование приложения Spring Boot.
2. Ошибка «Не удалось загрузить ApplicationContext»Нагрузочное тестирование является важной частью жизненного цикла разработки программного обеспечения (SDLC) для современных корпоративных приложений. В этом руководстве мы будем использовать коллекции Postman для выполнения простого нагрузочного тестирования .
Мы можем загрузить и установить настольный клиент , совместимый с операционной системой нашей системы. Кроме того, мы можем создать бесплатную учетную запись Postman и получить доступ к веб-клиенту .
Теперь давайте создадим новую коллекцию под названием «Google Apps — нагрузочное тестирование», импортировав несколько примеров HTTP-запросов, доступных в Postman's Collection Format v2.1:
В этой статье мы продемонстрируем несколько аспектов генерации отчетов о покрытии кода с помощью Cobertura .
Проще говоря, Cobertura — это инструмент отчетности, который вычисляет покрытие тестами для кодовой базы — процент ветвей/строк, к которым обращаются модульные тесты в проекте Java.
В этом кратком руководстве мы покажем, как тестировать конечные точки GraphQL с помощью Postman.
Мы будем использовать конечные точки, созданные в нашем руководстве по GraphQL . Напоминаем, что схема содержит определения, описывающие посты и авторов:
type Post {
id: ID!
title: String!
text: String!
category: String
author: Author!
}
type Author {
id: ID!
name: String!
thumbnail: String
posts: [Post]!
}
В этой статье мы представим HtmlUnit, инструмент, который позволяет нам, проще говоря, программно взаимодействовать с HTML-сайтом и тестировать его, используя JAVA API .
HtmlUnit — это браузер без графического интерфейса пользователя, предназначенный для программного использования, а не непосредственно пользователем.
Браузер поддерживает JavaScript (через движок Mozilla Rhino ) и может использоваться даже для веб-сайтов со сложными функциями AJAX. Все это можно сделать, имитируя типичный браузер с графическим интерфейсом, такой как Chrome или Firefox.
Покрытие кода — это программная метрика , используемая для измерения того, сколько строк нашего кода выполняется во время автоматизированных тестов.
В этом руководстве мы рассмотрим некоторые практические аспекты использования JaCoCo, генератора отчетов о покрытии кода для проектов Java.
Тестирование программного обеспечения относится к методам, используемым для оценки функциональности программного приложения. В этой статье мы собираемся обсудить некоторые метрики, используемые в индустрии тестирования программного обеспечения, такие как покрытие кода и мутационное тестирование , с особым интересом к тому, как выполнить мутационное тестирование с помощью библиотеки PITest .
Для простоты мы собираемся основывать эту демонстрацию на базовой функции палиндрома. Обратите внимание, что палиндром — это строка, которая читается одинаково вперед и назад.
Как видно из конфигурации зависимостей Maven, мы будем использовать JUnit для запуска наших тестов и библиотеку PITest для внедрения мутантов в наш код — не волнуйтесь, через секунду мы увидим, что такое мутант. Вы всегда можете найти последнюю версию зависимостей в центральном репозитории maven, перейдя по этой ссылке .
Spring REST Docs создает документацию для служб RESTful, которая является точной и удобочитаемой. Он сочетает в себе рукописную документацию с автоматически сгенерированными фрагментами документов, созданными с помощью тестов Spring.
Одной из основных философий проекта является использование тестов для создания документации. Это гарантирует, что всегда создаваемая документация точно соответствует фактическому поведению API. Кроме того, выходные данные готовы для обработки Asciidoctor , цепочкой инструментов публикации, основанной на синтаксисе AsciiDoc. Это тот же инструмент, который используется для создания документации Spring Framework.
Эти подходы уменьшают ограничения, налагаемые другими фреймворками. Spring REST Docs создает точную, краткую и хорошо структурированную документацию. Затем эта документация позволяет потребителям веб-сервисов получать необходимую им информацию с минимальными усилиями.