paul-rogers commented on PR #12545:
URL: https://github.com/apache/druid/pull/12545#issuecomment-1146472579
@cheddar, per your suggestion, extended the framework to capture results.
That wasn't quite as easy as it looked...
Took your suggestion to represent results as JSON arrays per row. Result
comparison is textual unless an option is set to force Java-object comparison,
which parses the JSON array into Java objects, and uses approximate equality
for floating-point values. (The parsed Java objects are often not the same type
as those produced in Druid results, so did some magic to make it work.)
The results handle SQL-compatible nulls or not, in the same run. No need to
manually change properties to run one way, then the other. This double-duty
occurs only in if `-Ddruid.debug=true` is provided, else the tests run as other
tests: use whatever mode Travis provides.
The runs handle the "vectorize or not" cases also, as well as the join
provider class that offers up to eight different ways to set options. This
gives up to a total of 32 runs per test case.
When all is happy, and everything works the same way for every variation,
the test case is pretty simple. But, when the native query (or results) differ
depending on SQL-compatible setting, or other variations, there are ways to
capture this variation.
You mentioned having a way to load data from an external file. That would be
a good addition: have the JUnit test case use your framework to load the data,
then run the tests using this mechanism.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
