You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "John Roesler (Jira)" <ji...@apache.org> on 2019/12/10 15:52:00 UTC

[jira] [Created] (KAFKA-9289) consolidate all the streams smoke system tests

John Roesler created KAFKA-9289:
-----------------------------------

             Summary: consolidate all the streams smoke system tests
                 Key: KAFKA-9289
                 URL: https://issues.apache.org/jira/browse/KAFKA-9289
             Project: Kafka
          Issue Type: Bug
          Components: streams
            Reporter: John Roesler


As of the addition of a relational smoke test (https://issues.apache.org/jira/browse/KAFKA-9138) we now have three "smoke test" applications in Streams, which are used across a variety of system tests.

This might be fine, since each test's existence doesn't hurt the others. However, there are a few drawbacks to the proliferations of smoke test applications to consider:
* if each application is different, and they are used in different scenarios in the system tests, then our coverage of Streams is lower than it could be.
* the older smoke tests are written in ways that tend to make them more prone to false positives. In KAFKA-9138, I have adopted a different paradigm to attempt avoiding this fate.

For these reasons, it would be a good exercise to attempt the following plan:
1. Expand the new RelationalSmokeTest introduced in KAFKA-9138 to include all the stream processing operations from the other smoke tests, but written and verified in the same style as the RelationalSmokeTest.
2. Add a new verification component for the RelationalSmokeTest to make some assertions about it when EOS is disabled. But be careful to account for the fact that without EOS, some operators can "overcount".
3. Expand the streams_relational_smoke_test system test to also run the same scenarios (with and without EOS) as the other smoke system tests.
4. Remove the other system tests and associated smoke test classes.

Note that this work should certainly be broken up into a series of pull requests so that each one is as small as possible while also being a sensible contribution on its own. Perhaps following the above plan.

Also note that this would resolve https://issues.apache.org/jira/browse/KAFKA-8080 as well.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)