-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add test
Jinja tag
#3261
Add test
Jinja tag
#3261
Conversation
@@ -250,9 +250,6 @@ def _inject_ctes_into_sql(self, sql: str, ctes: List[InjectedCTE]) -> str: | |||
|
|||
return str(parsed) | |||
|
|||
def _get_dbt_test_name(self) -> str: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wee, since we don't prepend tests with count(*)
when "compiling" this can go away!
core/dbt/utils.py
Outdated
def get_test_macro_name(test_name, with_prefix=True): | ||
name = f'test_{test_name}' | ||
|
||
if with_prefix: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Use ternary here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is backwards compatible in a very clever way, and I had to spend a few minutes thinking about it to really get it. Nice work!
A few things worth calling out, either because I think we should eventually document them, or because it reorients my own thinking:
- Test blocks are still technically macro nodes, just like materializations. As long as that's true, some of our other work around "configuring" generic tests (e.g. from
dbt_project.yml
) will have to work a bit differently. I actually think that's ok! - A test node named
my_test
cannot coexist with a macro namedtest_my_test
. I suppose the same is true of a materialization namedmy_mtzn
and a macro namedmaterialization_my_mtzn
. - If users are commonly calling other macros from within a test block, it's more likely that they will encounter the v0.19.1 regression (
config()
block orref
not properly accounted for), which @gshank is fixing by sticking the top-level test macro into the capture context. Once more, I think that's ok: We can tell users they need to hoist ref/source/config within the main test block to achieve the functionality they're after.
04ba591
to
a651a69
Compare
a651a69
to
3860d91
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very slick! thanks for adding all the comments 🥇
addresses part of #1173
Description
This PR adds a
test
Jinja tag. This gives us the ability to treat tests differently than very specifically defined macros. There is no change in behavior with this PR.Checklist
CHANGELOG.md
and added information about my change to the "dbt next" section.