Split up test_dataflow_to_sql_plan module into more manageable components #836
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The test_dataflow_to_sql_plan module has become a dumping ground for a mixture of direct tests of DataflowPlan to SqlQueryPlan object conversion and tests which are more about query rendering for a variety of metric queries. In preparation for splitting the latter class of tests into their own location, we consolidate the former class into a single block at the top of the module for ease of review.
The dataflow_to_sql_converter fixture was scoped to the package containing the plan_conversion tests, but it's useful anywhere we need an initialized DataflowToSqlQueryPlanConverter built on our most common simple semantic manifest. Since we're splitting up the plan_conversion tests into plan conversion and query rendering, it makes sense to hoist this out to where we define our more broadly available fixtures.
The snapshot generator script had a typo in it preventing any non-duckdb engine from executing. It also shifted to a mark based filter which excluded all engine-agnostic snapshots from regeneration. Since we can rapidly execute those tests without needing an external connection this simply runs a broader set of tests in duckdb, and relies on the mark for our other engine tests.
This is step 1 of the grand effort to break up test_dataflow_to_sql_plan. Here we move the grab bag of query rendering tests exercising basic conversion from metric queries to rendered SQL. Subsequent changes will move more focused testing areas, such as cumulative metrics, derived metrics, and granularity/date part adjustments, to their own modules.
|
Current dependencies on/for this PR: This stack of pull requests is managed by Graphite. |
|
Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide. |
This was referenced Nov 3, 2023
tlento
added
the
Run Tests With Other SQL Engines
tlento
temporarily deployed
to
DW_INTEGRATION_TESTS
GitHub Actions
Inactive
tlento
temporarily deployed
to
DW_INTEGRATION_TESTS
GitHub Actions
Inactive
tlento
temporarily deployed
to
DW_INTEGRATION_TESTS
GitHub Actions
Inactive
tlento
temporarily deployed
to
DW_INTEGRATION_TESTS
GitHub Actions
Inactive
github-actions
bot
removed
the
Run Tests With Other SQL Engines
|
Quick note - the convert_and_check helper added here removes all of the SqlQueryPlan output because it isn't terribly useful for these more complex rendered queries, and fewer generated files seemed better. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is step 1 of the grand effort to break up test_dataflow_to_sql_plan.
Here we move the grab bag of query rendering tests exercising basic
conversion from metric queries to rendered SQL. This naturally follows
some smaller changes which ensure the tests still function correctly.
Subsequent changes will move more focused testing areas, such as
cumulative metrics, derived metrics, and granularity/date part
adjustments, to their own modules.