Fast follows for Unit Testing

[matthewshaver]

Contributions

• I have read the contribution docs, and understand what's expected of me.

Link to the page on docs.getdbt.com requiring updates

https://docs.getdbt.com/reference/node-selection/methods#the-test_type-method

What part(s) of the page would you like to see updated?

can we update this page too with the new test_types

Additional information

No response

[matthewshaver]

Add format types

Add best practices for when to run unit tests

[matthewshaver]

Add format section to explain dict and csv data formats

[matthewshaver]

One more section here on "When to run your unit tests"

Like the general best practice on "run your unit tests in dev / ci" but not in prod - and maybe some thoughts/best practices around warehouse sizing?

[graciegoheen]

Oooh can we update this page too with the new test_types -> https://docs.getdbt.com/reference/node-selection/methods#the-test_type-method

[graciegoheen]

dbt build (how unit tests fit into the dbt build command)

docs for dbt build with unit tests

[graciegoheen]

Likely out of scope of this PR, but do we have an open issue already for documenting data_tests:?

For for backward compatibility tests: will be an alias for data_tests: in yml configuration files, but we will eventually deprecate tests:

models:
  - name: orders
    columns:
      - name: order_id
        data_tests:
          - unique
          - not_null

# dbt_project.yml

data_tests: # legacy tests:

[graciegoheen]

Link to docs for --empty flag

[matthewshaver]

We need to update the dbt build command page as well

[graciegoheen]

Really love how you nested data tests and unit tests under a "tests" section - I wonder if it would be valuable to have an "About dbt tests" page (similar to the "About dbt models") to talk more broadly about what "tests" are and how they're used. Could reduce some of the duplication of docs between data / unit (like the dbt test command).

We could also put some of the "this is how data tests and unit tests relate to each other" type of info on that page.

Maybe out-of-scope for this initial pass, but just a thought!

[graciegoheen]

I like how for the data tests ref section we have mini pages for the configs you can use for your data tests:

Could we do the same for unit tests? I think we could break up the "about writing unit tests" section into separate pages on format, expect, given, overrides, etc.

[graciegoheen]

Nit-pick:
the actual logs have some specific formatting (color + bolding) to make this error message clearer to read - would it be possible to include that formatting here?

• "Fail 1" is red
• "Complete with 1 error and 0 warnings:" is red
• "Failure in unit_test test_is_valid_email_address (models/marts/unit_tests.yml)" is red
• "actual" is green
• "expected" is red
• "True" is red and bold
• "False" is green and bold

[graciegoheen]

Same nit-pick as above:

• "PASS" is green
• "Completed successfully" is green

[graciegoheen]

add overrides examples for vars, macros, and env_vars https://github.com/dbt-labs/dbt-core/blob/7df747ae04a8c99dbd745085f42cd4647ec71d80/tests/functional/unit_testing/fixtures.py#L82

[graciegoheen]

IMPORTANT -> We should make it clear that unit tests must be defined in a YML file in your models/ directory in the unit testing docs

[matthewshaver]

Likely out of scope of this PR, but do we have an open issue already for documenting data_tests:?

For for backward compatibility tests: will be an alias for data_tests: in yml configuration files, but we will eventually deprecate tests:

models:
  - name: orders
    columns:
      - name: order_id
        data_tests:
          - unique
          - not_null

# dbt_project.yml

data_tests: # legacy tests:

Created this issue and will follow up!