-
Notifications
You must be signed in to change notification settings - Fork 0
Planner Tests
- Unit testing - maintain existing tests
- Integration tests - use existing tests in a full server
- Additional plan state capture for use in catalog, operators project
- Unit tests tied to
BaseCalciteQueryTest
which is tied to the test infra setup. - PR to compartmentalize the above, with plan to make it Guice-based
- Proposal for a separate planner test framework
- But, there is push-back that it may be too complex, two ways to do things
- Plans for eventual single-server deployment model
- But, not there yet. When it is, tests should run against full server in this mode
- Revise the current refactor PR to create a test builder
- Current set of test functions are a wrapper on top of the builder
- Need a way to handle setup done outside of the test function (vectorize, etc.)
- Both Calcite test, and the proposed framework, use the same test builder, infra
- Evolve infra to be Guice based
- Create a data set for ITs that mimics that used in UTs
- Use the builder, revised framework, and above data to run UT queries in ITs
- When single-serve is available, reuse same code to run in that mode
- Both approaches use a test builder, test fixture
- Calcite tests wrap the builder
- Easy path to explicitly use the builder, but must use clone of the
testQuery
functions. - Each test captures state to implicitly pass into the builder (i.e. vectorize)
- Planner test use file format to build the same test
- Test fixture does requested comparisons
- Calcite version set up to do only the existing comparisons
- In framework refactor, add the test builder
- Revisit planner test files PR to ensure that the tests can use the framework
- Later (?), extend fixture to handle additional items from planner test
Inputs:
- Vectorize option
- SQL
- Context
- Parameters
- Auth
- Query log hook
Verifications:
- Native query (as an object)
- Native query (as text)
- Expected results
- Expected exception
- Verify resources
There are many variables and modes. It will be hard to handle them all in one big class. Find a way to decompose.
- Stack of runners, each of which does some specific setup. Generalize from calcite tests, planner tests.
- Query runner with set of capture objects, set can influence setup, grabs and holds results
- Verification objects which take an expected value and capture to verify state.
- Builder which gathers all the options
- Analyzer to convert options to the items listed above
Planner test plan
Goal:
- Guice based in both paths
- Start with Calcite Test
Thoughts:
-
Start with the existing per-test injector.
-
Turn into a shared injector later
-
Leave test code in base Calcite test
-
The existing thing works, but is not Guice focused
-
Planner tests need more control, hence the builder
-
One path is to evolve the current stuff toward a builder
-
The core issue seems to be the schema, conglomerate mess
-
So, first step is to wrap what's there? New builder?
-
Convert existing tests.
Details:
BeforeClass:
- ResourceCloser
- Conglomerate
Before:
- Walker - createQuerySegmentWalker(), is overridden
- Engine - createEngine(), is overridden
- Object mapper - CalciteTests
- getJacksonModules() - is overridden
Other:
-
createOperatorTable(), many overrides
-
createMacroTable(), three overrides
-
createMockRootSchema() called only from getSqlStatementFactory
Tables are created in the testQuery stack.
Try layers injectors.
Start with per-test creation, as today. It is OK for the current tests to be overly aggressive, as long as the new ones can share code and have greater control.
First step is to refactor based on non-guide structure (but with Guide in mind). Then switch to Guice.