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

[Feature] Sync unit tests with model enabled/disabled config #10193

Closed
3 tasks done
pedrochazarra-aily opened this issue May 21, 2024 · 1 comment
Closed
3 tasks done
Labels
enhancement New feature or request unit tests Issues related to built-in dbt unit testing functionality wontfix Not a bug or out of scope for dbt-core

Comments

@pedrochazarra-aily
Copy link

pedrochazarra-aily commented May 21, 2024

Is this your first time submitting a feature request?

  • I have read the expectations for open source contributors
  • I have searched the existing issues, and I could not find an existing issue for this feature
  • I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature

It would be nice to have the functionality where unit tests are synchronised with the corresponding model enabled/disabled config. This means that if a model is disabled, the corresponding unit tests for the model are also disabled. The unit test will be enabled or disabled depending on the config for the model it references to.

In the current release (v1.8.0) if a model with unit tests is set as disabled, the build will fail with the following error:

Parsing Error
  Unable to find model 'app.model' for unit test 'unit_test_name' in 'path/to/unit_test'. 

This behaviour also occurs even if the flag --exclude-resource-type unit_test is specified. The parser fails because it’s unable to find the model because it's disabled, even though the unit tests will not be executed.

There is an ongoing issue [CT-3398] that it has already been proposed but it should be complementary.

Describe alternatives you've considered

No response

Who will this benefit?

DBT Users: It will make it easier to maintain unit tests associated to models.

Are you interested in contributing this feature?

No response

Anything else?

No response

@pedrochazarra-aily pedrochazarra-aily added enhancement New feature or request triage labels May 21, 2024
@dbeatty10 dbeatty10 added the unit tests Issues related to built-in dbt unit testing functionality label May 21, 2024
@dbeatty10 dbeatty10 self-assigned this May 21, 2024
@dbeatty10
Copy link
Contributor

This is an interesting idea @pedrochazarra-aily ! 💡

Disabling downstream resources

One way to reframe your proposal is that:

  • any unit test downstream of a disabled model should also be disabled

If we take a broader view, we could imagine expanding this to include any downstream resource (unit test, data test, another model, etc.). We can see how this could be useful -- with one config change of enabled=false, a node and all its downstream descendants could be excluded from running in the DAG.

Practical considerations

From a practical perspective, even if we wanted this behavior, I suspect this would be non-trivial for us to implement. Whether or not a node is enabled affects if it is added to the DAG. And to determine if one node is downstream of another or not requires the information in the DAG. So there would be a chicken-egg problem.

Currently available: --exclude flag

There is a mechanism to get similar behavior though: the --exclude flag combined with the plus operator:

dbt build --exclude "my_model_to_exclude+"

As an alternative to adding one-off CLI flags, exclusions can also be added to YAML Selectors, and you can set a default selector.

The one caveat is that:

If I run a command that defines its own selection criteria (via --select, --exclude, or --selector), dbt will ignore the default selector and use the flag criteria instead. 👉 It will not try to combine the two. 👈

Currently available: comment out the unit test

Another way is to comment out any downstream unit test (as mentioned in #9109 (comment)).

The trade-off is that there could be multiple downstream unit tests, and they could reside in different files. So it would carry some amount of burden depending on the volume of unit tests and the frequency of enabling/disabling upstream models.

Summary

Since we already have multiple ways to achieve this behavior, I'm going to close this as not planned.

@dbeatty10 dbeatty10 closed this as not planned Won't fix, can't repro, duplicate, stale May 21, 2024
@dbeatty10 dbeatty10 added wontfix Not a bug or out of scope for dbt-core and removed triage labels May 21, 2024
@dbeatty10 dbeatty10 removed their assignment May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request unit tests Issues related to built-in dbt unit testing functionality wontfix Not a bug or out of scope for dbt-core
Projects
None yet
Development

No branches or pull requests

2 participants