В первой части серии – Тестирование плагинов Maven – По-современному – Часть I мы видели, как выполнить базовую настройку с помощью Платформа интеграционного тестирования и запустите очень простой интеграционный тест.
В этой второй части мы более подробно рассмотрим другие аспекты тестирования плагинов Maven, в частности, как мы проверяем выходные данные журнала процесса сборки Maven.
Давайте начнем с написания более чем одного интеграционного тестового примера. Конечно, вы можете написать несколько тестовых примеров в рамках одного тестового класса, например, следующим образом:
@MavenJupiterExtension
class SeveralMavenIT {
@MavenTest
void the_first_test_case(MavenExecutionResult result) {
...
}
@MavenTest
void the_second_test_case(MavenExecutionResult result) {
...
}
@MavenTest
void the_third_test_case(MavenExecutionResult result) {
...
}
}
Помимо самих тестовых примеров нам нужны соответствующие проекты, которые используются в качестве тестовых проектов, которые выглядят следующим образом:
.
└── src/
└── test/
└── resources-its/
└── org/
└── it/
└── SeveralMavenIT/
├── the_first_test_case/
│ ├── src/
│ └── pom.xml
├── the_second_test_case/
│ ├── src/
│ └── pom.xml
└── the_this_test_case/
├── src/
└── pom.xml
Итак, после того, как мы выполним интеграционные тесты ( mvn verify ), результирующая структура каталогов будет выглядеть следующим образом:
.
└──target/
└── maven-it/
└── org/
└── it/
└── SeveralMavenIT/
├── the_first_test_case/
│ ├── .m2/
│ ├── project/
│ │ ├── src/
│ │ ├── target/
│ │ └── pom.xml
│ ├── mvn-stdout.log
│ ├── mvn-stderr.log
│ └── other logs
├── the_second_test_case/
│ ├── .m2/
│ ├── project/
│ │ ├── src/
│ │ ├── target/
│ │ └── pom.xml
│ ├── mvn-stdout.log
│ ├── mvn-stderr.log
│ └── mvn-arguments.log
└── the_third_test_case/
├── .m2/
├── project/
│ ├── src/
│ ├── target/
│ └── pom.xml
├── mvn-stdout.log
├── mvn-stderr.log
└── mvn-arguments.log
Основываясь на результирующей структуре каталогов, вы можете видеть, что каждый тестовый пример полностью отделен друг от друга. Это также означает, что каждый тестовый пример содержит свой собственный кэш maven ( .m2/repository ). Вы также можете найти отдельные выходные данные файла журнала и отдельный project каталог, содержащий тестовый проект после тестового запуска. Это очень полезно для последующего анализа проблем.
Итак, теперь давайте глубже рассмотрим тестовые примеры:
@MavenTest
void the_first_test_case(MavenExecutionResult result) {
}
В каждом тесте вы видели параметр метода тестирования MavenExecutionResult result/| . Введенный параметр предоставляет вам доступ к результату тестовой сборки проекта.
Этот класс содержит соответствующие методы для доступа к результату процесса сборки, кэшу проекта, самому проекту (другими словами, к каталогу) и, конечно же, к различным выходным файлам журнала, которые были созданы во время выполнения теста.
Итак, первое, что вы обычно проверяете, – это была ли сборка успешной или нет. Это зависит от типа интеграционного теста, который вы пишете. Этого можно достичь, используя следующее:
assertThat(result).isSuccessful();
Это предполагает, что сборка будет успешной, как вы уже подозревали. Вы, конечно, можете написать тест, который предполагает, что ваша сборка должна завершиться неудачей, что может быть выражено следующим образом:
assertThat(result).isFailure();
Таким образом, is Successful() означает код возврата 0 принимая во внимание, что is Failure() представляет собой код возврата, который не является 0 .
Вы можете объединить проверку успешной сборки и вывод без предупреждения следующим образом:
assertThat(result)
.isSuccessful()
.out()
.warn().isEmpty();
Итак .out () получит доступ к созданному выходному файлу сборки mvn-stdout.log . .предупреждать () отфильтрует все строки, начинающиеся с [ПРЕДУПРЕЖДЕНИЕ] . .Пусто () является частью AssertJ фреймворка для утверждения по спискам, что подразумевает, что результат пуст.
Итак, теперь давайте проверим некоторые выходные данные, которые создаются обычной сборкой. На выходе выдается [INFO] таким образом, тест может использовать .out().info (). вместо этого, который выглядит следующим образом:
@MavenJupiterExtension
class FirstIT {
void base_test (MavenExecutionResult result) {
assertThat(result)
.isSuccessful()
.out()
.info()
.containsSubsequence(
"--- maven-enforcer-plugin:3.0.0-M1:enforce (enforce-maven) @ kata-fraction ---",
"--- jacoco-maven-plugin:0.8.5:prepare-agent (default) @ kata-fraction ---",
"--- maven-resources-plugin:3.1.0:resources (default-resources) @ kata-fraction ---",
"--- maven-compiler-plugin:3.8.1:compile (default-compile) @ kata-fraction ---",
"--- maven-resources-plugin:3.1.0:testResources (default-testResources) @ kata-fraction ---",
"--- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ kata-fraction ---",
"--- maven-surefire-plugin:3.0.0-M4:test (default-test) @ kata-fraction ---",
"--- maven-jar-plugin:3.2.0:jar (default-jar) @ kata-fraction ---",
"--- maven-site-plugin:3.9.1:attach-descriptor (attach-descriptor) @ kata-fraction ---"
);
}
}
.containsSubsequence(..) проверяет, что последовательность находится в правильном порядке с дополнительными дополнительными частями между ними.
При написании плагинов/расширений иногда случается, что вы выдаете информацию на уровне ПРЕДУПРЕЖДЕНИЯ, чтобы дать некоторые подсказки о том, что необходимо упомянуть, но не приведет к сбою сборки.
Например, maven-jar-plugin выдаст предупреждение, если в jar не будет добавлено никакого содержимого. Это можно проверить следующим образом:
assertThat(result)
.isSuccessful()
.out()
.warn()
.contains("JAR will be empty - no content was marked for inclusion!");
Таким образом, это можно объединить, чтобы создать более полный тестовый пример, подобный этому:
@MavenJupiterExtension
class FailureIT {
@MavenTest
void basic_configuration_checking_logout(MavenExecutionResult result) {
assertThat(result)
.isSuccessful()
.out()
.info()
.containsSubsequence(
"--- maven-enforcer-plugin:3.0.0-M1:enforce (enforce-maven) @ basic_configuration_checking_logout ---",
"--- jacoco-maven-plugin:0.8.5:prepare-agent (default) @ basic_configuration_checking_logout ---",
"--- maven-resources-plugin:3.1.0:resources (default-resources) @ basic_configuration_checking_logout ---",
"--- maven-compiler-plugin:3.8.1:compile (default-compile) @ basic_configuration_checking_logout ---",
"--- maven-resources-plugin:3.1.0:testResources (default-testResources) @ basic_configuration_checking_logout ---",
"--- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ basic_configuration_checking_logout ---",
"--- maven-surefire-plugin:3.0.0-M4:test (default-test) @ basic_configuration_checking_logout ---",
"--- maven-jar-plugin:3.2.0:jar (default-jar) @ basic_configuration_checking_logout ---",
"--- maven-site-plugin:3.9.1:attach-descriptor (attach-descriptor) @ basic_configuration_checking_logout ---"
);
assertThat(result)
.isSuccessful()
.out()
.warn()
.contains("JAR will be empty - no content was marked for inclusion!");
}
}
Если вы пишете плагин, который содержит параметр для кодирования, должен быть создан такой вывод (который может показаться вам знакомым).:
Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
Это можно проверить в рамках такого тестового примера, как этот:
assertThat(result)
.out()
.warn()
.containsExactly("Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!");
Итак, это относится ко второй части. Если вы хотите узнать больше о Платформе интеграционного тестирования , вы можете ознакомиться с руководством пользователя . Если вы хотите узнать о состоянии выпуска, вы можете заглянуть в примечания к выпуску .
Если у вас есть идеи, предложения или обнаруженные ошибки, пожалуйста, напишите в выпуске на github .
Пример можно найти на GitHub .
Оригинал: “https://dev.to/khmarbaise/maven-plugin-testing-in-a-modern-way-part-ii-i3k”