[
https://issues.apache.org/jira/browse/CALCITE-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228857#comment-15228857
]
Julian Hyde commented on CALCITE-1190:
--------------------------------------
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.
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)
