Skip to content
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

Initial pass at switching integration tests to pytest #4691

Merged
merged 6 commits into from
Feb 22, 2022
Merged

Conversation

gshank
Copy link
Contributor

@gshank gshank commented Feb 7, 2022

resolves #4690

Description

This pull request is for preliminary review of the state of the integration test conversion to pytest.

Checklist

  • I have signed the CLA
  • I have run this code in development and it appears to resolve the stated issue
  • This PR includes tests, or tests are not required/relevant for this PR
  • I have updated the CHANGELOG.md and added information about my change

@gshank gshank requested review from a team as code owners February 7, 2022 01:54
@gshank gshank requested review from emmyoop and leahwicz and removed request for a team February 7, 2022 01:54
@cla-bot cla-bot bot added the cla:yes label Feb 7, 2022
@gshank gshank removed the request for review from a team February 7, 2022 01:54
@gshank gshank marked this pull request as draft February 7, 2022 01:55
@gshank gshank requested a review from jtcohen6 February 7, 2022 01:55
Copy link
Contributor

@jtcohen6 jtcohen6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really exciting!! Lots of comments as I read through the draft implementation.

As next steps, I'd be excited to:

  • Try porting the two converted integration tests to an adapter plugin, and see how we'd need to reimplement fixtures/methods/etc
  • Think about what other modular utilities we'd want, in a similar vein to get_manifest. I think @JCZuurmond's work on pytest-dbt-core could be generative here, especially macro_generator to mock macro input + output. Could that do for "execution" code what get_manifest does for "parsing" code?

tests/tables.py Outdated Show resolved Hide resolved
tests/util.py Outdated Show resolved Hide resolved
tests/util.py Outdated Show resolved Hide resolved
tests/functional/conftest.py Outdated Show resolved Hide resolved
tests/functional/simple_copy/test_mixed_case_db.py Outdated Show resolved Hide resolved
tests/functional/simple_copy/test_copy_uppercase.py Outdated Show resolved Hide resolved
tests/functional/simple_reference/test_simple_reference.py Outdated Show resolved Hide resolved
Comment on lines 133 to 142
'advanced_incremental.sql': advanced_incremental_sql,
'compound_sort.sql': compound_sort_sql,
'disabled.sql': disabled_sql,
'empty.sql': empty_sql,
'get_and_ref.sql': get_and_ref_sql,
'incremental.sql': incremental_sql,
'interleaved_sort.sql': interleaved_sort_sql,
'materialized.sql': materialized_sql,
'schema.yml': schema_yml,
'view_model.sql': view_model_sql,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we aim to consolidate these fixtures with the ones used in other tests? It would require more upfront work, but if we assembled a common set of standard fixtures (rather than recreating highly similar ones over and over again), then:

  • each test can pick & choose just the ones it needs
  • adapter plugins could reimplement specific fixtures (as needed) among the standard reused set, and then be able to get most tests "for free," rather than needing to reimplement similar fixtures in similar ways for each test

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally I think it would be nice to have some standard projects that can be reused. We have a lot of tests that create projects with only subtle or minimal differences. That can be done a directory basis, using a test directory conftest.py, with only the different parts overridden. We probably could do that for test_simple_copy.py and test_copy_upperbase, and just override the 'models' fixture for test_copy_upperbase. You can also make individual sets of project fixtures with different names and include them in a test as a plugin.

I think it will be easiest to do that after we've converted the tests though, since we'll then be able to more easily see the differences between test projects. The legacy tests with all the files in directories (often multiple) makes that sort of comparison harder.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though on second thought, if people see the same setup as they're going through converting, there's no reason to wait. "Oh, I saw this project before. Yank! It's now a plugin."

tests/CONVERTING.md Show resolved Hide resolved
Copy link
Contributor

@JCZuurmond JCZuurmond left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, super nice you are upgrading the testing framework! I added some comments, I am still thinking about how I would do this myself, view the comments as suggestions, probably some education is needed before I understand the intent of the changes.

It is great to remove all the dbt subprocess calls as this allows the user to start debugging sessions.

Furthermore, it would be great to have a test suite which can be applied to the core and all the adapters. Especially, if it is written in such a way that adapters can easily extended it (for example with adapter specific settings) whilst reusing the test suite.

Pytest recommends two test layouts: outside or inside the package. The most common set-up is having your tests outside of your package: this makes your package smaller. However, some packages don't do this (for example numpy).

A benefit of having the tests inside your package is that you can run the test suite as a user. This could be helpful for the adapters:

  1. Install dbt-core: pip install dbt-core
  2. Run dbt-core test suite: pytest --pyargs dbt
    If then the test suite is set-up to automatically pick up which adapter is installed, you can reuse that test suite for every adapter.

As mentioned in the comments, I don't think fixtures are usually shipped inside the package. If you want to reuse a fixture over different projects, I think the idea is to write a pytest plugin.

core/dbt/tests/tables.py Show resolved Hide resolved
core/dbt/tests/tables.py Show resolved Hide resolved
core/dbt/tests/tables.py Show resolved Hide resolved
core/dbt/tests/tables.py Show resolved Hide resolved
core/dbt/tests/util.py Show resolved Hide resolved
core/dbt/tests/fixtures/project.py Show resolved Hide resolved
tests/functional/basic/test_jaffle_shop.py Outdated Show resolved Hide resolved
core/dbt/tests/fixtures/project.py Show resolved Hide resolved
@gshank gshank force-pushed the testing_rewrite branch 12 times, most recently from 2c054b2 to f552cfa Compare February 17, 2022 21:18
@gshank gshank force-pushed the testing_rewrite branch 6 times, most recently from 63c460b to 6e48fbf Compare February 18, 2022 00:54
@gshank gshank force-pushed the testing_rewrite branch 4 times, most recently from 3dcea97 to fc4adda Compare February 18, 2022 03:28
@gshank gshank marked this pull request as ready for review February 18, 2022 13:44
@gshank gshank requested a review from a team February 18, 2022 13:44
@gshank gshank requested a review from a team as a code owner February 18, 2022 13:44
Author: Emily Rockman <emily.rockman@dbtlabs.com>
Date:   Thu Feb 10 15:45:47 2022 -0600

    route logs to dbt-core/logs instead of each test folder (#4711)

commit 507184f
Author: Gerda Shank <gerda@dbtlabs.com>
Date:   Thu Feb 10 16:22:20 2022 -0500

    Initial pass at switching integration tests to pytest
Add comments, cleanup adapter schema setup
@gshank gshank requested a review from ChenyuLInx February 20, 2022 22:37
Copy link
Member

@emmyoop emmyoop left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good with the understanding that we'll make changes as needed as we learn more/establish patterns.

@gshank gshank merged commit 8fd8dfc into main Feb 22, 2022
@gshank gshank deleted the testing_rewrite branch February 22, 2022 20:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[CT-169] Initial conversion of integration tests to pytest
4 participants