Продолжая важную для обучения разработчиков распределенных приложений и дата-инженеров тему про тестирование Big Data систем на базе Apache Kafka, сегодня рассмотрим некоторые средства для создания интеграционных тестов.
Краткий ликбез по интеграционному тестированию приложений Apache Kafka
В отличие от модульного тестирования, которое мы разбирали ранее, интеграционное тестирование сосредоточено на интерфейсах и потоке данных между отдельными модулями. Фокус на интеграции между разными единицами программного кода (функции, компоненты, модули), а не их непосредственной работоспособности, которая уже проверена в ходе unit-тестирования. При интеграционном тестировании программные модули объединяются логически и тестируются как группа, чтобы выявить ошибки взаимодействия между разными единицами кода, включая обмен данными между ними. Про другие виды тестирования, применяемые на разных этапах разработки ПО, мы уже писали здесь.
Вспомнив про основное назначение интеграционного тестирования, рассмотрим, как это реализуется при разработке приложений Apache Kafka. В частности, в библиотеке org.apache.kafka:kafka-streams-test-utils есть несколько встроенных классов, которые пригодятся при интеграционном тестировании приложений. Одним из которых является класс EmbeddedKafkaCluster, запускающий кластер Kafka в памяти с 1 экземпляром Zookeeper и настраиваемым количеством брокеров.
class MyKafkaStreamIntegrationTest{
@ClassRule
val cluster = EmbeddedSingleNodeKafkaCluster()
@BeforeAll
fun setup() {
cluster.createTopic(myTopic)
// ... other setup
}
// ... startup app and test
Однако, эта встроенная библиотека – не единственная возможность интеграционного тестирования распределенных приложений потоковой передачи событий. Можно также применить некоторые сторонние инструменты, что мы и рассмотрим далее.
Библиотека Spring EmbeddedKafka
Также можно использовать стороннюю библиотеку Spring EmbeddedKafka из пакета org.springframework.kafka:spring-kafka-test, которая дает доступ к встроенному экземпляру Kafka в памяти, работающему на локальном хосте 9092. Чтобы использовать его, нужно просто аннотировать свой тестовый класс с помощью EmbeddedKafka:
@SpringBootTest
@DirtiesContext // if have more than one test class using kafka
@EmbeddedKafka(partitions=1, brokerProperties = {..}
class MySpringIntegrationTest{
// startup your app and assert
}
При этом стоит помнить типовое ограничение Spring-приложений: когда доступен контекст тестового приложения, темы и свойства брокера могут содержать заполнители ранее определенных свойств, которые будут разрешены. Если контекст Spring недоступен, эти заполнители не будут разрешены.
Начиная с версии Spring 2.3, есть два способа использования аннотации @EmbeddedKafka со средой модульного тестирования Java-приложений JUnit5. При использовании с аннотацией @SpringJunitConfig встроенный брокер добавляется в контекст тестового приложения, позволяя автоматически подключить брокера к тесту на уровне класса или метода, чтобы получить список адресов брокера.
Если контекст Spring-теста не используется, EmbdeddedKafkaCondition создает брокера; условие включает преобразователь параметров, поэтому получить доступ к брокеру можно в своем тестовом методе.
Тестовые контейнеры (Testcontainers)
На практике экземпляры в памяти немного отличаются от фактической реализации Kafka и Zookeeper. Поэтому есть возможность использовать Docker-контейнер для пользовательского KafkaContainer:
KafkaContainer kafka = KafkaContainer(DockerImageName.parse(“confluentinc/cp-kafka:6.2.1”)) // configure kafka.start()
Тестовые контейнеры можно использовать для автоматического создания экземпляров контейнеров Apache Kafka и управления ими. Testcontainers использует официальные образы Docker для Confluent OSS Platform, позволяя запускать установку Kafka с одним узлом всего одной строкой кода без необходимости управлять внешней установкой Zookeeper.
Библиотека Charithe’s Kafka-JUnit
Наконец, отметим не совсем стандартную библиотеку Charithe’s Kafka-JUnit, которая предоставляет несколько удобных методов с реализациями сред модульного тестирования JUnit версий 4 и 5. Она помогает запускать и отключать брокеры Kafka во время тестов. В инфраструктуре тестирования JUnit 4 следует создать экземпляр правила в своем тестовом классе и аннотировать его с помощью @Rule. Это запустит и остановит брокер между каждым тестовым вызовом. Для запуска брокера в начале набора тестов и отключения в конце используется @ClassRule:
@ClassRule public static KafkaJunitRule kafkaRule = new KafkaJunitRule(EphemeralKafkaBroker.create());@ExtendWith(KafkaJunitExtension.class) @KafkaJunitExtensionConfig(startupMode = StartupMode.WAIT_FOR_STARTUP
На kafkaRule можно ссылаться из методов тестирования, чтобы получить информацию о брокере Kafka. В JUnit 5 можно применять KafkaJunitExtension, который предоставляет брокера, который запускается и останавливается для каждого теста. Расширение настраивается с помощью необязательной аннотации класса @KafkaJunitExtensionConfig и обеспечивает внедрение зависимостей для конструкторов и методов классов KafkaHelper и EphemeralKafkaBroker. EphemeralKafkaBroker содержит базовую логику, используемую правилом JUnit, и может использоваться независимо. KafkaHelper содержит множество удобных методов для работы с EphemeralKafkaBroker.
Как улучшить планирование интеграционных тестов Kafka-приложений с помощью FMECA-анализа, читайте в нашей новой статье. А всю практику тестирования и разработки распределенных приложений с Apache Kafka для потоковой аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков больших данных в Москве:
Источники
- https://betterprogramming.pub/testing-kafka-applications-libraries-for-unit-and-integration-tests-732c0f13b915
- https://logrocon.ru/news/intgration_testing
- https://github.com/charithe/kafka-junit
- https://www.testcontainers.org/modules/kafka/
- https://docs.spring.io/spring-kafka/reference/html/#embedded-kafka-annotation
