[
https://issues.apache.org/jira/browse/CALCITE-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228857#comment-15228857
]
Julian Hyde edited comment on CALCITE-1190 at 4/6/16 6:42 PM:
--------------------------------------------------------------
Makes sense. You're talking about what I call a TCK. It is a module that can be
used by another product to create a test suite. The other product implements
callbacks to provide the test environment, and runs the TCK as part of its own
test suite.
I just created olap4j-tck which is very similar:
https://github.com/olap4j/olap4j/tree/olap4j2/tck. Note that the code lives
under src/main/java (not src/test/java) and it depends on junit (not in test
scope). Mondrian provides an olap4j driver, and uses olap4j-tck to make sure
that its olap4j driver is compliant. There is an assumption that any user of
the tck would provide the same basic schema (in the case of olap4j-tck, that is
the Foodmart Sales cube).
was (Author: julianhyde):
Makes sense. You're talking about what I call a TCK. It is a module that can be
used by another product to create a test suite. The other product implements
callbacks to provide the test environment, and runs the TCK as part of its own
test suite.
I just created olap4j-tck which is very similar:
https://github.com/olap4j/olap4j/tree/olap4j2/tck. Note that the code lives
under src/main/java (not src/test/java) and it depends on junit (not in test
scope).
> Cross-Version Compatibility Test Harness
> ----------------------------------------
>
> Key: CALCITE-1190
> URL: https://issues.apache.org/jira/browse/CALCITE-1190
> Project: Calcite
> Issue Type: Test
> Components: avatica
> Reporter: Josh Elser
> Assignee: Josh Elser
> Fix For: avatica-1.8.0
>
>
> One thing that the Protobuf serialization aimed to provide was a library
> which provides us the tools to make Avatica compatible across versions.
> However, Protobuf is just a tool and the developers can still misuse protobuf
> in such a way that breaks compatibility across versions. Not to mention,
> compatibility isn't even remotely certain without any tests.
> Because of Avatica's position as a library less than a product, we have to
> defer some logic to the concrete product being tested (e.g. Phoenix or
> Drill). I'm thinking something like the following:
> The user provides pairs of client and server "definitions" for a given
> version of compatibility. This would include some version of Avatica and some
> backing database. For example, Avatica-1.7.1 and Phoenix-4.7.0 or
> Avatica-1.8.0-SNAPSHOT and HSQLDB-2.3.1.
> The client half would be some template for the appropriate JDBC url to use
> (sans the URL to the Avatica server) and a JAR file containing the necessary
> classes to run the j.s.Driver. The server half would just be a URL to the
> Avatica server instance.
> The test harness itself can provide the logic to test the remote driver
> against the other servers, enumerating the possible combinations of
> client-server communication. Starting the server for each version to test is
> likely too difficult to automate well given the unknown of what the server
> will be, so that will be left as a prerequisite.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
