tnightengale/dbt-meta-testing

Regex Test Name Matching Not Working As Per Documentation

Closed this issue · 2 comments

This is great, thank you! I am working on integrating this into one of my larger dbt projects

I don't think that test name matching is working exactly as per this, which is from the documentation:

For example, in the dbt_project.yml above, the path configuration on the marts model path requires each model in that path to have at least one test that either starts with unique or is an exact match for the not_null test.

I think it's not actually checking for exact matches, but rather just the presence of the string of the test name specified in the dbt_project.yml file in the possibly-larger string that is the actual test name in the model .yml files.

For example, I have one model that uses the dbt_utils.unique_combination_of_columns test. If I do this in my dbt_project.yml file, it seems to count the "unique_combination_of_columns" test as satisfying the requirement for a "unique" test:

  +required_tests:
    "unique": 1

Here is the .yml from the file in question:

tests:
  - dbt_utils.unique_combination_of_columns:
      combination_of_columns:
        - project
        - dataset
        - model_name

However, if I use regex anchors like this:

  +required_tests:
    "^unique$": 1

Then the "unique_combination_of_columns" test does not count to satisfy the testing requirement.

I can make it match both cases by doing this:

  +required_tests:
    "^unique$|^unique_combination_of_columns$": 1

I'm fine with having to be explicit with the test names, although it would be a bit nicer to not have to specify anchors. I just wanted to point out that the docs don't quite match with the actual experience, I am not 100% sure what the intended functionality was in this case?

@codigo-ergo-sum Great call out! I will correct the docs shortly!

Unfortunately, I think the flexibility gained with the re.match functionality is worth the necessity of regex anchors, so I think the path forward is to be very explicit that keys are evaluated that way.

This is fixed in 0.3.3 with the substitution of re.fullmatch for re.match.