Testing

Hi, I'm Sophie Blee-Goldman here with Confluent. And in this module, we're going to talk about testing with Kafka streams. Testing is a pretty critical part of software development, especially with applications that you're writing, you're gonna want to unit or integration test them. And this can be a little tricky with Kafka streams because Kafka streams by its nature connects to brokers, and you don't necessarily want to set up a whole cluster just to write a unit test. Now, for one thing, it can be kind of inconvenient to set up a whole cluster and for another it's expensive. Your tests will take longer because they rely on these connections that they're making to the broker and these messages getting sent across the network. Now you can't really avoid that with integration tests and you should always have some integration tests but with the unit tests, you don't necessarily want to be involving a broker. And this is where the Topology Test Driver comes in. The topology test driver is really a Kafka streams answer to unit tests. You wanna make sure that the custom logic in your topology is producing the correct results, and that's where the topology test driver comes in. So how do you actually use the topology test driver? To use it, you just build a topology as usual with the same configurations that you would use to set up your Kafka streams application. You might wonder what if you're using Schema Registry? Well, there's a Mock Schema Registry that Kafka streams provides, which you can use to mock the actual schema registry so that you don't need a schema registry cluster, similarly to how it essentially does away with the need for a broker cluster. Now, once you have your topology, all you need to do is instantiate the topology test driver and pass it in your topology and these configurations. This basically represents the Kafka streams application itself, so now it's on you to create some test input topics and some input. So the test input topic is what you will create and use with the topology test driver. You just create that and then you can pipe input with the test input topic pipe input method. Now, all you need to do here is send in normal key value objects. This represent the records that you would have coming in from a broker. And there are various overloaded methods that allow for providing timestamps lists more just general convenience methods, but fundamentally you're just writing records as you would to a normal topic but instead to this test input topic. Now some interesting things to note about the test input topic, executing this pipe input will actually trigger a stream time punctuation. So, this is just part of the nature of the test input topic that it can provide normal stream time punctuations. Does not provide wall clock punctuations because punctuations that go by wall clock time can be a little bit hard to test deterministically. And it's important part of your tests that they are reproducible and not resulting in potentially flaky test failures or something that you can't quite verify. So instead of going by actual wall clock time passage and the topology test driver, you need to use the advanced wall clock time method to actually advance time and that gives you control over the way that wall clock time advances as opposed to trying to sleep on your thread or something else that is just not as precise. Now some good practices for writing testable applications. You'll notice that the streams DSL had a lot of operators that accept SAM interfaces or functional interfaces. This is convenient for writing an application because you can just use a Lambda expression. It's less code in general, and you can just do it completely in line, but this has the downside that you can't as easily test that same Lambda in isolation. It's going to be much more convenient for you to test the arguments to these map values or reduce methods if you actually write a concrete implementation of the interface instead of using a Lambda. That way you can write unit tests for each of your value mappers or your reducers, all of these things in isolation, to make sure that each step of the way has been thoroughly tested and give you greater confidence that all the pieces are working together. Of course, the only way to know if things really work together is through integration tests. You know, a unit test will test whether each piece itself is working, but you can't really get a good sense of that unless you have a full integration test. Now there's some cases where integration test really is necessary. For example, if you use patterns subscription, that's when you instead of passing in a topic name, you just pass in a pattern, regex that the broker will match to the topic names and subscribe whatever matches. In that case, you might be interested in what happens to your application when a new topic that matches the regex is created or a topic that matches the regex disappears. That's not really something that you can test using the topology test driver because there are no brokers. So these sort of events that happen in the surrounding environment, you're going to need actual integration tests for, with a live broker. Another reason that the topology test driver does not quite catch every single thing that you would want in an integration test is that it doesn't really test the full caching behavior and other behavior that stateful operations might have. So instead of caching, it will output every single record that is processed, which is not the same way that Kafka streams itself will process things, unless of course you have set the cach in the commit interval to zero. It also doesn't write to real topics, so you might wanna make sure that you are writing to the correct topic, whether that be something that is dynamically determined at runtime or an actual topic that you will read from later. Now, how do you write integration test in Kafka streams? The best choice for using brokers in a test is to use test containers. So test containers also make it possible to share a container across multiple test classes, which is important because this saves you from having to set up the broker and tear it down each time for every single integration test. This helps your test run faster when they can share the same resources rather than doing the same set up and clean up that you would for each single test and generally just wasting time. So while it's important to have integration tests, the topology test driver is generally going to be your best friend with Kafka streams testing. So, now we're going to go over an exercise to see what that actually looks like in action.