Belajar Apache Kafka - Testing Strategies

#Pendahuluan

Kode yang memakai Kafka bisa terasa sulit diuji: butuh broker, waktu asinkron, dan dependency eksternal. Akibatnya banyak tim melewati testing dan membayar dengan bug di produksi. Padahal ada strategi berlapis yang membuat pengujian Kafka mudah dan bermakna.

Episode 32 ini akan membahas empat lapis pengujian: unit test untuk logika producer, consumer, dan topologi Streams; integration test dengan embedded Kafka dan Testcontainers; performance test dengan tool resmi; serta chaos engineering untuk menguji perilaku saat kegagalan nyata.

#Unit Testing

#Testing Producers dan Consumers

Unit test fokus pada logika, bukan pada Kafka. Untuk producer, mock kliennya:

MockProducer<String, String> mock = new MockProducer<>(
    true, new StringSerializer(), new StringSerializer());
 
OrderProducer producer = new OrderProducer(mock);
producer.sendOrder("order-001");
 
List<ProducerRecord<String, String>> history = mock.history();
assertEquals("orders", history.get(0).topic());

MockProducer menangkap record tanpa memerlukan broker, sehingga kalian bisa memverifikasi topic, key, dan value dengan cepat. Untuk consumer, pola yang sama memakai MockConsumer untuk menyimulasikan poll dan offset.

#Testing Kafka Streams Topologies

Kafka Streams menyediakan TopologyTestDriver untuk menjalankan topologi secara deterministik:

TopologyTestDriver driver = new TopologyTestDriver(builder.build(), props);
TestInputTopic<String, String> input =
    driver.createInputTopic("orders", new StringSerializer(), new StringSerializer());
input.pipeInput("order-001", "PAID");
 
TestOutputTopic<String, String> output =
    driver.createOutputTopic("paid-orders", new StringDeserializer(), new StringDeserializer());
assertEquals("PAID", output.readValue());

TopologyTestDriver menjalankan topologi dalam memori tanpa Kafka — waktu bisa dimajukan secara virtual, dan output diverifikasi langsung. Ini cara tercepat menguji logika stream processing.

#Mocking Kafka

Untuk aplikasi non-Java atau kebutuhan umum, mock framework (Mockito, atau library seperti kafka-node-test-utils) menggantikan klien Kafka. Prinsipnya sama: verifikasi perilaku kode kalian tanpa infrastruktur nyata.

#Integration Testing

#Embedded Kafka

Untuk memastikan interaksi nyata dengan protokol Kafka, gunakan embedded Kafka: broker yang berjalan dalam proses test. Library seperti kafka-junit atau spring-kafka-test memulai broker di background saat test dan mematikannya setelahnya. Cocok untuk test suite yang cepat dan tanpa Docker.

#Testcontainers

Testcontainers menjalankan Kafka di dalam Docker saat test:

docker run -p 9092:9092 apache/kafka:3.7.1

Secara konseptual, Testcontainers melakukan hal di atas secara terprogram: container dimulai, aplikasi test terhubung ke localhost:9092, lalu container dibersihkan otomatis. Keunggulannya: versi Kafka persis seperti produksi, dan seluruh stack (broker + Schema Registry) bisa diuji bersama.

#Test Fixtures dan Schema Tests

• Fixtures: sediakan data awal realistis untuk setiap test, dari topic dan offset hingga state store.
• Schema compatibility tests: daftarkan skema baru ke Schema Registry dan uji bahwa versi lama masih kompatibel (backward/full) sebelum dipakai produksi.

#Performance Testing

#kafka-producer-perf-test dan Consumer

Tool resmi untuk benchmark:

bin/kafka-producer-perf-test.sh --topic orders \
  --num-records 1000000 --record-size 1024 \
  --throughput -1 --producer-props bootstrap.servers=localhost:9092

kafka-producer-perf-test.sh mengirim 1 juta record 1KB tanpa membatasi throughput, lalu melaporkan records/sec, MB/sec, dan percentiles latensi. Ini baseline yang jujur untuk menilai tuning episode 21.

#Benchmarking dan Latency Measurement

Metodologi yang baik: ukur baseline, ubah satu parameter, ukur lagi. Laporkan percentiles (p50, p99, p999) — rata-rata menyesatkan untuk latensi. Jalankan dengan cluster yang realistis (bukan single broker) dan cukup lama untuk mencapai kondisi stabil.

#Chaos Engineering

#Broker Failure Scenarios

Chaos testing menguji perilaku saat kegagalan nyata. Skenario umum:

• Broker failure: matikan satu broker; verifikasi leader election, durasi ketidaktersediaan, dan recovery.
• Network partition: isolasi broker dari jaringan; amati efek pada ISR dan tulis.
• Slow consumer: buat consumer lambat; amati lag dan rebalance.
• Rebalance storm: restart banyak consumer sekaligus; amati apakah rebalance berulang (storm) dan dampak latency.

#Praktik Chaos yang Aman

Mulai di staging, bukan produksi. Gunakan tool seperti Chaos Monkey atau skrip sederhana yang mematikan pod broker (episode 28). Pastikan monitoring (episode 22) menangkap setiap fase, dan tentukan metrik keberhasilan sebelum memulai: misalnya, ketidaktersediaan tulis tidak melebihi X detik dan tidak ada data yang hilang.

#Penutup

Di episode 32 ini kalian sudah memahami strategi testing berlapis: unit test dengan mocking dan TopologyTestDriver, integration test dengan embedded Kafka dan Testcontainers, performance test dengan tool resmi, serta chaos engineering untuk kegagalan nyata.

Inti yang harus dibawa pulang:

• Unit test memverifikasi logika dengan mock tanpa broker.
• TopologyTestDriver menguji topologi Streams secara deterministik.
• Testcontainers menguji interaksi nyata dengan versi Kafka produksi.
• kafka-producer-perf-test memberi baseline throughput dan latensi.
• Ukur percentiles, bukan rata-rata, untuk latensi.
• Chaos test menguji failover dan rebalance dalam lingkungan yang aman.

Di episode 33 selanjutnya kita akan membahas security best practices dan compliance — hardening dengan least privilege dan network segmentation, kepatuhan GDPR dengan retention dan audit log, pemantauan keamanan, serta secure development dengan secret management dan scanning.