-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: add RestQueryTranslationTest #3291
Conversation
This is along the same lines as `QueryTranslationTest`, but comes in through the front door of the REST Api. It's currently much more limited in its functionality, but can extended as needed to be it more inline with QTT functionality. QTT should still do the brunt of the work, with RQTT only being used where QTT will no suffice, e.g. `INSERT VALUE` statement test, or the upcoming static query work.
To allow TestCaseNode to be reused by other computation, split the computation out and leave a Pojo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've had a pass through. Can we add a readme or doc-string somewhere explaining when to use RQTT instead of QTT? Would it be possible to automate a warning - e.g. if we see a test case with no insert-into or iq usage?
ksql-functional-tests/src/main/java/io/confluent/ksql/test/tools/TestCaseBuilderUtil.java
Outdated
Show resolved
Hide resolved
) { | ||
final String format = explicitFormat.orElse(FORMAT_REPLACE_ERROR); | ||
|
||
return statements.stream() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will cause a parse error down the line if there is no format, right? Consider just checking for {FORMAT} and throwing here if no format is provided.
.collect(Collectors.toList()); | ||
} | ||
|
||
public static Map<String, Topic> getTopicsByName( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A doc-string would help here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, this is just moved code. I'm trying to move fast here. Sure, a lot of this code could do with refactoring, docs, tests, etc - but I see this PR as moving in the right direction, not the final state.
The old code had no docs, hence the moved code remains with no docs
ksql-functional-tests/src/main/java/io/confluent/ksql/test/model/TopicNode.java
Outdated
Show resolved
Hide resolved
ksql-functional-tests/src/test/java/io/confluent/ksql/test/rest/model/ExpectedErrorNode.java
Show resolved
Hide resolved
}); | ||
} | ||
|
||
private static void verifyResponses( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we expect the exact response (as specified in the test spec) here? If so, should we run with EOS to try and avoid flakiness? Alternatively, we could loosen our checks below to allow for at-least-once results.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is something I've considered. I don't think loosening our checks is sufficient, as without EOS aggregates can get the wrong value.
Let's see how we go and enable EOS if we think its needed.
ksql-functional-tests/src/test/java/io/confluent/ksql/test/rest/RestTestExecutor.java
Outdated
Show resolved
Hide resolved
)); | ||
} | ||
|
||
private static void throwIfMoreOutputAvailable( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't used anywhere. Should it get called above?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, no. Unfortunately, @hjafarpour dropped this functionality in the new code paths :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All I can do in this PR is remove the unused method :'(
|
||
testCase.expectedException().map(ee -> { | ||
throw new AssertionError("Expected test to throw" + StringDescription.toString(ee)); | ||
}); | ||
|
||
writeInputIntoTopics(testCase.getInputRecords(), fakeKafkaService); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not part of your diff but this seems weird. We write all the input records to the kafka fake, but they are never read from there. Later in this method we just write these directly into the test driver.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
God knows - this code is a mess. But outside the scope of this PR.
.getSource(persistentQueryMetadata.getSinkName()) | ||
.getKafkaTopicName(); | ||
|
||
final SerdeSupplier<?> keySerdes = SerdeUtil.getKeySerdeSupplier( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this all just validation? Would help to add a comment explaining why we need to build all this stuff (and seemingly drop it on the floor)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not new code, just moved - as I said in the description, please refrain from asking for improvements in this code. I agree it needs improvement, but this is outside the scope of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Description
This is along the same lines as
QueryTranslationTest
, but comes in through the front door of the REST Api.It's currently much more limited in its functionality, but can extended as needed to be it more inline with QTT functionality.
QTT should still do the brunt of the work at it runs ~ 5 times quicker, with RQTT only being used where QTT will no suffice, e.g.
INSERT VALUE
statement test, or the upcoming static query work.I've added an example test in
rest-query-translation-tests/insert-values.json
This PR also includes a change to QTT: if the expected output record does not have
timestamp
defined then the timestamp of the output is not checked. Before this PR you could omittimestamp
from both input and output records, but this just set it to zero. This is still the case for input records. This change means system generated timestamps, e.g. like those generated by someINSERT VALUE
statements don't mean you can't test it with (R)QTT.Reviewing notes:
I've lift and shifted a load of code out of
QueryTranslationTest
andEndToEndIntegrationTestUtil
into some newTestLoader
s.JsonTestLoader
loads JSON based tests from a directory, andExpectedTopologiesTestLoader
which deals with combining the loaded JSON tests with their expected-topology files, and into the existingTopologyFileGenerator
. NOTE This code generally hasn't be refactored, just moved - please refrain from raising loads of changes in this code. The purpose of this PR is not to refactor all this code, just to restructure it so it can be shared.Likewise, the computation has been pulled out of
TestCase
and into theTestExecutor
class, leavingTestCase
as a Pojo. NOTE: again, this is a pick and shift of code: please refrain from reviewing line-by-line. We know this code needs improvement / refactoring.There is a new
VersionedTest
, which extends the currentTest
interface with the bitsExpectedTopologiesTestLoader
needs to do its work.Many bits of code have been changed to reflect the fact that the input/output
Record
might not have an explicit timestamp.I've added some functionality to embedded kafka code to allow us to delete all the topics, except the command topic.
Testing done
mvn test
.Reviewer checklist