-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
create a happy path project fixture #10291
Conversation
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. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #10291 +/- ##
==========================================
- Coverage 88.74% 88.71% -0.03%
==========================================
Files 180 180
Lines 22495 22483 -12
==========================================
- Hits 19963 19946 -17
- Misses 2532 2537 +5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
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.
Looks good to me! Thank you for doing this work 🙂
I do have some questions in regards to how things changed. They aren't blocking questions, but I'd like to discuss them so I can better understand how the code is functioning. Most of these occur in the fix
commits. It'd be amazing to have some of that context in the commit messages themselves.
@@ -56,7 +42,7 @@ def expect_given_output(self, args, expectations): | |||
else: | |||
assert got == expected | |||
|
|||
def expect_snapshot_output(self, project): | |||
def expect_snapshot_output(self, happy_path_project): # noqa: F811 |
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.
In this test we're actually using the happy_path_project
fixture argument in the function. Is the # noqa: F811
necessary for another reason?
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.
+1, also curious about this
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.
I think for whatever reason flake8 was complaining about all of these in my local dev environment.
Let me try again and see what happened 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 the problem with pytest, I don't see a easy way of getting rid of it.
https://stackoverflow.com/questions/50268284/why-im-getting-f811-error-in-this-code
@@ -724,12 +710,12 @@ def expect_resource_type_env_var(self): | |||
} | |||
del os.environ["DBT_EXCLUDE_RESOURCE_TYPES"] | |||
|
|||
def expect_selected_keys(self, project): | |||
def expect_selected_keys(self, happy_path_project): # noqa: F811 |
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.
In this test we're actually using the happy_path_project fixture argument in the function. Is the # noqa: F811
necessary for another reason?
core/dbt/tests/fixtures/project.py
Outdated
project_files, | ||
project_setup: TestProjInfo, | ||
project_files, |
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.
I'm not asking for a change here, but I would like to understand the context. Does the ordering of the fixture arguments here mean something? Is there a reason the project_setup
fixture has to be come before project_files
? This is the kind of thing I would love to see in a commit comment so that I can better understand why something is changing while reviewing.
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.
Yes, adding a comment in the following commit.
The order of the argument determines the order of fixtures being executed(if they need to).
So we do all setups, then write the project files. Setup should be independent of project file write.
Another reason is for the happy path fixture, we do not use the dbt_project.yml
fixture, instead, we want to use the files in the fixture folder, changing the order makes sure that the tests run with the intended files
@pytest.fixture(scope="class") | ||
def project_files( | ||
project_root, | ||
tests, | ||
models, | ||
selectors_yml, | ||
): | ||
write_project_files(project_root, "tests", tests) | ||
write_project_files(project_root, "models", models) |
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.
Were we able to remove this because of the existing more widely available project_files
satisfied the relevant tests? I'm trying to understand if this is extraneous cleanup or if it was necessary for some reason in regards to the happy path testing we are setting up in this branch.
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.
Yes, they are covered by the project_files.
And the reason they are being removed is they failed to write certain files(like dbt_project.yml), they might not be relevant anymore with the order of writing project files but I think it is still good to remove.
@@ -0,0 +1,8 @@ | |||
|
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.
super nit: looks like a lot of these files have an extra empty line at the top of the file, could we clean that up?
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.
Sounds good!
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.
Not necessarily blocking but I would like to understand the necessity for the new # noqa: F811
usages with happy_path_project
since we'll probably start seeing those all over the place once we migrate more tests to using happy_path_project
.
resolves #10256
Problem
We are missing a central place to define a happy path project that contains a bit of everything to be reused across different tests.
Solution
We are adding a
happy_path_project
fixture that will give integration tests a project to use