History

Gian Merlino 3d19b748fb SQL OperatorConversions: Introduce.aggregatorBuilder, allow CAST-as-literal. (#14249 ) * SQL OperatorConversions: Introduce.aggregatorBuilder, allow CAST-as-literal. Four main changes: 1) Provide aggregatorBuilder, a more consistent way of defining the SqlAggFunction we need for all of our SQL aggregators. The mechanism is analogous to the one we already use for SQL functions (OperatorConversions.operatorBuilder). 2) Allow CASTs of constants to be considered as "literalOperands". This fixes an issue where various of our operators are defined with OperandTypes.LITERAL as part of their checkers, which doesn't allow casts. However, in these cases we generally _do_ want to allow casts. The important piece is that the value must be reducible to a constant, not that the SQL text is literally a literal. 3) Update DataSketches SQL aggregators to use the new aggregatorBuilder functionality. The main user-visible effect here is [2]: the aggregators would now accept, for example, "CAST(0.99 AS DOUBLE)" as a literal argument. Other aggregators could be updated in a future patch. 4) Rename "requiredOperands" to "requiredOperandCount", because the old name was confusing. (It rhymes with "literalOperands" but the arguments mean different things.) * Adjust method calls.		2023-06-23 16:25:04 -07:00
..
cases	Skip tests based on files changed in the PR (#14445 )	2023-06-22 12:27:23 +05:30
docs	Extend the IT framework to allow tests in extensions (#13877 )	2023-05-15 20:29:51 +05:30
image	Extend the IT framework to allow tests in extensions (#13877 )	2023-05-15 20:29:51 +05:30
tools	SQL OperatorConversions: Introduce.aggregatorBuilder, allow CAST-as-literal. (#14249 )	2023-06-23 16:25:04 -07:00
.gitignore	Docker build for the revised ITs (#12707 )	2022-08-10 14:17:33 +05:30
README.md	Code cleanup & message improvements (#13778 )	2023-02-15 15:22:54 +05:30

README.md

Revised Integration Tests

This directory builds a Docker image for Druid, then uses that image, along with test configuration to run tests. This version greatly evolves the integration tests from the earlier form. See the History section for details.

Shortcuts

List of the most common commands once you're familiar with the framework. If you are new to the framework, see Quickstart for an explanation.

Build Druid

./it.sh build

Build the Test Image

./it.sh image

Run an IT from the Command Line

./it.sh test <category>

Where <category> is one of the test categories.

Run an IT from the IDE

Start the cluster:

./it.sh up <category>

Where <category> is one of the test categories. Then launch the test as a JUnit test.

Background information

Next steps
Test conversion - How to convert existing tests.
History - Comparison with prior integration tests.

Goals

The goal of the present version is to simplify development.

Speed up the Druid test image build by avoiding download of dependencies. (Instead, any such dependencies are managed by Maven and reside in the local build cache.)
Use official images for dependencies to avoid the need to download, install, and manage those dependencies.
Make it is easy to manually build the image, launch a cluster, and run a test against the cluster.
Convert tests to JUnit so that they will easily run in your favorite IDE, just like other Druid tests.
Use the actual Druid build from distribution so we know what is tested.
Leverage, don't fight, Maven.
Run the integration tests easily on a typical development machine.

By meeting these goals, you can quickly:

Build the Druid distribution.
Build the Druid image. (< 1 minute)
Launch the cluster for the particular test. (a few seconds)
Run the test any number of times in your debugger.
Clean up the test artifacts.

The result is that the fastest path to develop a Druid patch or feature is:

Create a normal unit test and run it to verify your code.
Create an integration test that double-checks the code in a live cluster.