По умолчанию JUnit запускает тесты в детерминированном, но непредсказуемом порядке ( MethodSorters.DEFAULT ).
В большинстве случаев такое поведение совершенно нормально и приемлемо. Но бывают случаи, когда нам нужно обеспечить соблюдение определенного порядка.
В JUnit 5 мы можем использовать @TestMethodOrder для управления порядком выполнения тестов.
В этой статье мы увидим, как писать интеграционные тесты для веб-служб SOAP, созданных с использованием Spring Boot.
Мы уже знаем, как писать модульные тесты для классов приложений, и мы уже рассмотрели общие концепции тестирования в нашем руководстве по тестированию в Spring Boot . Итак, здесь мы сосредоточимся на интеграционном тестировании только уровня веб-сервиса, используя @WebServiceServerTest .
В Spring Web Services конечные точки являются ключевым понятием для реализации службы на стороне сервера. Специализированная аннотация @Endpoint помечает аннотированный класс как конечную точку веб-службы. Важно отметить, что эти конечные точки отвечают за получение сообщений запроса XML, вызов необходимой бизнес-логики и возврат результата в виде ответного сообщения .
JUnit — одна из самых популярных сред модульного тестирования в экосистеме Java. Версия JUnit 5 содержит ряд интересных нововведений с целью поддержки новых функций в Java 8 и более поздних версиях , а также обеспечения различных стилей тестирования.
Настройка JUnit 5.x.0 довольно проста; нам просто нужно добавить следующую зависимость в наш pom.xml :
В этой статье мы подробно рассмотрим утверждения, доступные в JUnit.
После статей о переходе с JUnit 4 на JUnit 5 и A Guide to JUnit 5 мы подробно рассмотрим различные утверждения, доступные в JUnit 4 и JUnit 5.
Мы также отметим улучшения, внесенные в утверждения с помощью JUnit 5.
В этой статье мы собираемся изучить библиотеку PDFUnit для тестирования PDF-файлов.
Используя мощные API, предоставляемые PDFUnit, мы можем работать с PDF-файлами и проверять текст, изображения, закладки и ряд других вещей.
Со временем мы сможем написать довольно сложные тестовые примеры с помощью PDFUnit, но давайте начнем с наиболее распространенных вариантов использования, которые будут применяться к большинству ваших производственных PDF-файлов и обеспечат отличную основу для дальнейшей разработки.
Важное примечание: PDFUnit доступен бесплатно для ознакомления, но не для коммерческого использования.
В этом руководстве мы познакомимся с Serenity BDD — отличным инструментом для применения Behavior Driven Development (BDD) . Это решение для автоматизированного приемочного тестирования, которое генерирует хорошо иллюстрированные отчеты о тестировании.
Концепции, лежащие в основе Serenity, следуют концепциям, лежащим в основе BDD. Если вы хотите узнать больше об этом, прочтите нашу статью о Cucumber и JBehave .
В этой статье мы кратко рассмотрим шаблон сценария в Serenity BDD. Мы предлагаем вам сначала прочитать основы Serenity BDD, прежде чем читать это. Также может быть интересна статья об интеграции Serenity BDD со Spring .
Сценарий, представленный в Serenity BDD, направлен на поощрение хороших привычек тестирования и хорошо разработанных наборов тестов, позволяя командам писать более надежные и надежные тесты. Он основан на Selenium WebDriver и модели Page Objects. Если вы читали наше введение в Selenium , вы найдете эти концепции довольно знакомыми.
Во-первых, добавим в файл pom.xml следующие зависимости :
В этой статье мы обсудим создание пользовательских журналов и отчетов с помощью TestNG.
TestNG предоставляет собственную функцию создания отчетов — создание отчетов в форматах HTML/XML. Если тесты выполняются с использованием подключаемого модуля maven-surefire, отчет будет иметь форму по умолчанию, определенную подключаемым модулем. Помимо встроенных отчетов, он предоставляет механизм для простой настройки регистрируемой информации и генерируемых отчетов.
Если вы хотите начать с основ TestNG, ознакомьтесь с этой статьей .
В этом кратком руководстве мы узнаем об исключении Mockito UnnecessaryStubbingException . Это исключение является распространенным исключением, с которым мы, вероятно, столкнемся при неправильном использовании заглушек.
Мы начнем с объяснения философии строгой заглушки и того, почему Mockito поощряет ее использование по умолчанию. Затем мы рассмотрим, что именно означает это исключение и при каких обстоятельствах оно может возникнуть. Наконец, мы увидим пример того, как мы можем подавить это исключение в наших тестах.
Чтобы узнать больше о тестировании с помощью Mockito, ознакомьтесь с нашей обширной серией статей о Mockito .
В этом коротком руководстве мы сосредоточимся на том, как смоделировать окончательные классы и методы с помощью Mockito.
Как и в других статьях, посвященных среде Mockito (например, Mockito Verify , Mockito When/Then и Mockito Mock Methods ), мы будем использовать класс MyList , показанный ниже, в качестве соавтора в тестовых примерах.
Мы добавим новый метод для этого руководства:
public class MyList extends AbstractList {
final public int finalMethod() {
return 0;
}
}
И мы также расширим его окончательным подклассом: