anchor.diff:  
   == Kafka embedded in the test
   
  -As both Kafka and Zookeeper are Java applications, it is possible to control them by calling their code. It is possible (have a look at https://github.com/apache/camel/blob/master/components/camel-kafka/src/test/java/org/apache/camel/component/kafka/embedded/EmbeddedKafkaBroker.java[camel-kafka] or https://github.com/danielwegener/logback-kafka-appender/blob/master/src/test/java/com/github/danielwegener/logback/kafka/util/EmbeddedKafkaCluster.java[logback-kafka-appender]), but is not easy.
  +As both Kafka and Zookeeper are Java applications, it is possible to control them from Java code. It is possible (have a look at https://github.com/apache/camel/blob/master/components/camel-kafka/src/test/java/org/apache/camel/component/kafka/embedded/EmbeddedKafkaBroker.java[camel-kafka] or https://github.com/danielwegener/logback-kafka-appender/blob/master/src/test/java/com/github/danielwegener/logback/kafka/util/EmbeddedKafkaCluster.java[logback-kafka-appender]), but is not easy.
   
   There are many libraries to run an embedded Kafka from JUnit without sweating:
   
   * https://github.com/charithe/kafka-junit[Kafka JUnit] by Charith Ellawala
   * Another https://mguenther.github.io/kafka-junit/[Kafka JUnit] by Markus Günther
   * https://docs.spring.io/spring-kafka/docs/2.2.6.RELEASE/reference/html/#testing[Spring Kafka Test] by the Spring team
  +
  +The drawback of this solution is that Kafka and Zookeeper servers are started in the same JVM as your test.
  +So one can fear unexpected behaviour.
   
   === Kafka JUnit
   
  
positive.code: You're developping a Java application plugged to Kafka, 
  or maybe you're programming a data processing pipeline based on Kafka Streams. How do you automate tests involving both Java code and Kafka brokers?
  
  Such an integrations should be able to
  
  . Start Zookeeper and then Kafka
  . Send messages into Kafka so as to trigger business code
  
negative.code: include::{sourcedir}/pom.xml[tags=containers]
  ----
  
  Testcontainers library is strongly integrated with JUnit 5, a single annotation and you're done. A JUnit 4 rule is also available.
  [source,java]
  ----
  include::{sourcedir}/src/test/java/com/github/gquintana/kafka/ContainersMessageServiceIT.java[tags=start]
  ----
  <1> Trigger Testcontainers start
  <2> Create a Kafka container. 
  	By default the https://hub.docker.com/r/confluentinc/cp-kafka[cp-kafka Docker image] created by Confluent is used. 
      As a consequence the version number matches the Confluent Platform version, not Apache Kafka.
      
  As Testcontainers is a generic library to run containers,
  there is no helper class to read/write messages.
  Starting a Docker container is slower than starting an embedded Kafka,
  but process isolation is stronger.
  You are starting the real thing, no hacked Kafka broker, so you are closer to production.
  3 Dockers containers are actually used by Testcontainers Kafka.
  
  == Kafka Consumer subscriptions
  
  Dealing with asynchronous code in tests is often painful, Kafka consumers don't help.
  
  It can take a long time for the consumer group controller to be elected, and partitions to be assigned. 
  Between the consumer bootstrap and the first messages being received,
  it can take a second or so.
  
  Using a `ConsumerRebalanceListener` to wait for partitions to be assigned and check which ones are assigned can be useful.
  
  The http://www.awaitility.org/[Awaitility] library can aleviate the burden of asynchronous testing.
  