Каково поведение @DirtiesContext при использовании вместе с KafkaEmbedded в модульных тестах?

Question

Я разрабатываю некоторые тесты приложения, которое использует Kafka-streams, которое также использует Spring Boot 1.5, который импортирует версию 1.2 из spring-kafka.Подробно, я использую KafkaEmbedded, чтобы не использовать реально работающий экземпляр Kafka.

Во многих примерах в сети я обнаружил, что конфигурация такого рода тестов использует аннотацию @DirtiesContext, например:в следующем (найдено здесь )

@RunWith(SpringRunner.class)
@SpringBootTest
@DirtiesContext
public class SpringKafkaReceiverTest {
    private static final Logger LOGGER = LoggerFactory.getLogger(SpringKafkaReceiverTest.class);

    private static String RECEIVER_TOPIC = "receiver.t";

    @Autowired
    private Receiver receiver;

    private KafkaTemplate<String, String> template;

    @Autowired
    private KafkaListenerEndpointRegistry kafkaListenerEndpointRegistry;

    @ClassRule
    public static KafkaEmbedded embeddedKafka = new KafkaEmbedded(1, true, RECEIVER_TOPIC);

    // Rest of tests body
}

Я немного погуглил, но не могу найти цель, которую стоит использовать @DirtiesContext.Может кто-нибудь прояснить мне этот вопрос?

Большое спасибо.

Answer 1

При использовании со встроенной кафкой @ClassRule, @DirtiesContext не влияет на брокера;брокер останавливается с помощью @AfterClass.

. Обычно мы рекомендуем использовать @DirtiesContext на уровне класса, потому что мы не хотим, чтобы инфраструктура тестирования кэшировала контекст приложения, поскольку в нем, вероятно, имеются активные компоненты (@KafkaListener и т. Д.).Мы хотим, чтобы они остановились, так как брокер будет убит при выходе из класса.

Если метод помечен @DirtiesContext в этом случае, он не имеет никакого эффекта.

Если встроенная кафкаопределенный как bean-компонент вместо @ClassRule, его жизненный цикл управляется контекстом приложения вместо JUnit.В этом случае уровень метода @DirtiesContext остановит посредника, а также аннотацию на уровне класса.

Answer 2

Из документов Spring :

@ DirtiesContext указывает, что базовый Spring ApplicationContext был загрязнен во время выполнения теста (т. Е. Изменен или поврежден каким-либо образом - дляНапример, путем изменения состояния одноэлементного бина) и должен быть закрыт.Когда контекст приложения помечается как грязный, он удаляется из кэша инфраструктуры тестирования и закрывается.Как следствие, базовый контейнер Spring будет перестроен для любого последующего теста, для которого требуется контекст с такими же метаданными конфигурации.

У меня нет опыта работы с spring-kafka, но я думаю, что онииспользуя его для очистки сообщений, сгенерированных тестом.Но было бы очень расточительно, чтобы в наборе тестов было много @DirtiesContext тестов, потому что контекст Spring не кэшируется.В больших проектах может потребоваться несколько минут, чтобы ускорить контекст Spring, поэтому такой аннотированный тест может занять очень много времени.

Поэтому я отступаю к @DitriesContext, только если нет другой опции.В случае KafkaEmbedded я бы поспорил, что есть способ отбросить все сообщения в @AfterClass тестовом хуке.