Current state: Accepted

Discussion threadhere

JIRAJIRA for adding initial ducktape testsJIRA for tracking porting of existing tests

Released: 0.8.3

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).


The existing system tests have been around for a few years, and technical debt has accrued. As Kafka matures, our system tests need to become first-class citizens so we can be more confident in the stability and performance of the overall system as well as compatibility from release to release.

From “things we can test” perspective, we need convenient ways to do things like:

From a usability perspective, we need:

Current system tests are:

Public Interfaces


Proposed Changes 

What do we want out of system tests going forward?

The basic proposal is to

  1. Develop new tests against the ducktape testing framework/library with the goal of filling out existing gaps in coverage.

  2. Gradually replace existing system_tests with tests using ducktape with the goal of removing the old system_test directory.

So why ducktape? To some extent, this is arbitrary, but there aren’t many existing options for running distributed system tests in a flexible way. We are developing ducktape itself as well as system tests against it at Confluent, and based on our experience with it so far, we think it represents a change in the right direction:

Some examples of tests are here

Compatibility, Deprecation, and Migration Plan

 What impact (if any) will there be on existing users?

If we are changing behavior how will we phase out the older behavior?

Rejected Alternatives

The other testing tool we considered was Zopkio. A viable option would have been to contribute the features we need to Zopkio, but ultimately we didn’t think it was the best choice for a few reasons, including:

A table comparing features is here.