[ 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:40 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). 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. 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)