Hi team,
Problem
Supporting custom Hamcrest matchers would significantly improve the developer experience by making test writing easier and more fluent (unit test or integration test).
Suggestion
I suggest to implement custom Hamcrest matchers to deal with TestRecord and ConsumerRecord to write concise and elegant assertions.
This will lead to a need of several utility classes to simplify the writing of tests.
The goal is also to have clear and intelligible diagnostic messages when tests fail.
Alternatives Considered
We could stay with standard JUnit assertions but I find we can have better mismatch description with custom matchers.
We could also use AssertJ that provides a fluent API and is also extensible.
Additional Context
Concerning the libraries I suggest:
- https://github.com/hamcrest/JavaHamcrest: popular, flexible and extensible matcher library. It enables developers to write custom matchers and compose them easily.
- https://github.com/awaitility/awaitility: popular utility library to synchronize asychronous orperations. Useful to consumer records in a Kafka topic with a polling duration and a tiemout.
- https://github.com/yegor256/mktmp: a tiny utility to create tmp directory in the Maven
target/ directory to store data in test. I think it's useful to store the state.dir to investigate in it after a failing test.
- https://github.com/yegor256/maybeslow: a tiny logging utility that notifies that a long test is running. I find it useful to know that integration (typically using
EmbeddedKafka or TestContainers) are still alive and running, with time progress.
Regards,
Romain
Hi team,
Problem
Supporting custom Hamcrest matchers would significantly improve the developer experience by making test writing easier and more fluent (unit test or integration test).
Suggestion
I suggest to implement custom Hamcrest matchers to deal with
TestRecordandConsumerRecordto write concise and elegant assertions.This will lead to a need of several utility classes to simplify the writing of tests.
The goal is also to have clear and intelligible diagnostic messages when tests fail.
Alternatives Considered
We could stay with standard JUnit assertions but I find we can have better mismatch description with custom matchers.
We could also use AssertJ that provides a fluent API and is also extensible.
Additional Context
Concerning the libraries I suggest:
target/directory to store data in test. I think it's useful to store thestate.dirto investigate in it after a failing test.EmbeddedKafkaorTestContainers) are still alive and running, with time progress.Regards,
Romain