This message was deleted.

Wow, super cool! The way tests are currently organized is the following: Each module has unit tests, and we measure coverage of the main code via jacoco. The coverage is segregated by module, which means that our true coverage is actually higher than what jacoco reports, if you consider cases where a module depends on another module, and the depender has a test that will end up exercising code in the dependee. Integration tests are all in

internal/venice-test-common/src/integrationtest

and we do not measure coverage for those (one reason being that we want to encourage writing unit tests, and another reason being that since integ tests tend to be non-deterministic, the code coverage is likewise non-deterministic, which makes it not that useful to look at). You can look at

ServiceFactory

for ways to spin up a whole Venice cluster in a test. You may need to override certain configs in there to turn on the modes you’re looking to test. The integ tests are split across many GH Actions for parallelism. The mapping of which tests go into which action is maintained in

internal/venice-test-common/build.gradle

and if you add a package which is not caught by any of the existing patterns, then your test will default to the

Z

bucket. Hope this helps… LMK if you have any other question! And we’ll look at your PR ASAP 😄

do you think it is worth to start a Kafka service with SASL enabled ? (I don’t think so)

Is it going to be possible to meaningfully test without that?