Skip to content
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

Merged
merged 9 commits into from
Sep 6, 2019

Conversation

big-andy-coates
Copy link
Contributor

@big-andy-coates big-andy-coates commented Sep 2, 2019

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 omit timestamp 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 some INSERT VALUE statements don't mean you can't test it with (R)QTT.

Reviewing notes:

  1. I've lift and shifted a load of code out of QueryTranslationTest and EndToEndIntegrationTestUtil into some new TestLoaders. JsonTestLoader loads JSON based tests from a directory, and ExpectedTopologiesTestLoader which deals with combining the loaded JSON tests with their expected-topology files, and into the existing TopologyFileGenerator. 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.

  2. Likewise, the computation has been pulled out of TestCase and into the TestExecutor class, leaving TestCase 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.

  3. There is a new VersionedTest, which extends the current Test interface with the bits ExpectedTopologiesTestLoader needs to do its work.

  4. Many bits of code have been changed to reflect the fact that the input/output Record might not have an explicit timestamp.

  5. 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

  • Ensure docs are updated if necessary. (eg. if a user visible feature is being added or changed).
  • Ensure relevant issues are linked (description should include text like "Fixes #")

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.
@big-andy-coates big-andy-coates requested a review from a team as a code owner September 2, 2019 17:00
To allow TestCaseNode to be reused by other computation, split the computation out and leave a Pojo.
Copy link
Contributor

@rodesai rodesai left a 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?

) {
final String format = explicitFormat.orElse(FORMAT_REPLACE_ERROR);

return statements.stream()
Copy link
Contributor

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(
Copy link
Contributor

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

Copy link
Contributor Author

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

});
}

private static void verifyResponses(
Copy link
Contributor

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.

Copy link
Contributor Author

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.

));
}

private static void throwIfMoreOutputAvailable(
Copy link
Contributor

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?

Copy link
Contributor Author

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 :(

Copy link
Contributor Author

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);
Copy link
Contributor

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.

Copy link
Contributor Author

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(
Copy link
Contributor

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)

Copy link
Contributor Author

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.

@big-andy-coates big-andy-coates requested review from rodesai and a team September 4, 2019 09:56
Copy link
Contributor

@rodesai rodesai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@big-andy-coates big-andy-coates merged commit 26af8d0 into confluentinc:master Sep 6, 2019
@big-andy-coates big-andy-coates deleted the rest_qtt branch September 6, 2019 07:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants