Dev
Générateur de messages Kafka fictifs
A mock Kafka message generator removes the friction of writing consumer tests without a live broker. This tool produces complete Kafka record objects — topic name, partition, offset, UUID key, typed headers, and a JSON payload — across five real event domains: user.created, order.placed, payment.processed, inventory.updated, and session.started. Each field mirrors exactly what a real consumer receives, so output pastes directly into a Spring Kafka test or a Kafka Streams TopologyTestDriver. Set your topic name, choose an event type, and generate up to a full batch in seconds. Developers building event-driven microservices use it to skip hand-crafting realistic fixture data from scratch. Typical uses include testing Spring Kafka @KafkaListener offset-commit logic using MockConsumer with generated record batches. The tool is completely free and runs in your browser, so you can generate as often as you like.
How to use
- Choose your options above
- Click Generate
- Copy your result
Detailed instructions
- Enter your Kafka topic name in the Topic Name field to match your actual topic, e.g. order-service.events.
- Select the Event Type that matches the domain you are testing — user.created, order.placed, or payment.processed.
- Set the How Many counter to the number of records your test scenario requires, then click Generate.
- Copy the generated JSON array and paste it into your unit test, MockConsumer setup, or kafka-console-producer input file.
- Adjust individual field values in the copied payload to cover edge cases like null amounts or missing user IDs.
Use Cases
- •Seeding a Kafka Streams TestInputTopic with realistic user.created events inside a JUnit 5 test suite
- •Testing Spring Kafka @KafkaListener offset-commit logic using MockConsumer with generated record batches
- •Creating dead-letter queue handler fixtures by generating payment.processed messages with edge-case field values
- •Demoing Kafka record anatomy — headers, UUID key, partition, offset — during microservices onboarding sessions
- •Replaying order.placed message batches through kafka-console-producer against a local Docker Kafka broker
Tips
- →Match the topic name exactly to your environment's naming convention so generated messages need no editing before use in tests.
- →Generate a batch of 10 or more, then cherry-pick specific records to cover both happy-path and failure scenarios in the same test suite.
- →The message key is a UUID by default — replace it with a fixed value when testing partition-ordered processing to ensure all test records land on the same partition.
- →Copy the headers object into a Spring Kafka MessageHeaders or a Flink KafkaRecordSerializationSchema to test header-aware consumer branches.
- →Combine payment.processed and user.created events in a single test to verify that your consumer correctly routes multiple event types from the same topic.
- →When testing offset-commit logic, edit the offset field in consecutive generated records to be sequential integers starting from a non-zero value, simulating a mid-stream consumer restart.
FAQ
how do I use generated kafka messages in a topologytestdriver test
Copy the generated JSON value into your test via TestInputTopic.pipeInput(), using the key field as the record key and mapping the headers object to a Kafka Headers instance. No broker is needed — TestInputTopic handles everything in-process. For Spring Kafka, drop the same payload into a MockConsumer or pass the key and value to an EmbeddedKafkaBroker to drive a real @KafkaListener.
are mock kafka messages safe to paste into ci pipelines or share with teammates
Yes. All messages are generated entirely in your browser — no data is sent to any server and no broker is contacted. The payloads are fully synthetic, so there is zero risk of leaking production event data. Commit the JSON output as a static test fixture and reference it in your pipeline like any other resource; tests using MockConsumer or TopologyTestDriver need no network access at all.
what's the difference between the kafka message key and the partition field
The key is a value you attach to a record — here a UUID — that Kafka's default partitioner hashes to decide which partition receives it. The partition is the broker-assigned integer bucket within the topic. Kafka guarantees ordering only within a single partition, so using a consistent key (like a user or order UUID) ensures all related events land in sequence.
What is the difference between the Kafka message key and the partition?
The key is a value attached to the message that Kafka hashes to decide which partition it lands in, so messages with the same key go to the same partition and keep their order. The partition is the actual numbered log the message is written to. The generator includes both so your mocks reflect how Kafka routes and orders events.
Are mock Kafka messages safe to share or commit?
Yes — the keys, values, and payloads are randomly generated and fictional, so they contain no real data and are safe to paste into tests, CI pipelines, or share with teammates. Use them to exercise consumers, serializers, and a TopologyTestDriver test without needing a live broker or real event data.
You might also like
Popular tools from other categories that share themes with this one.
Try these next
More free tools from other corners of the catalog, picked by shared themes.