dbt-unit-testing

We use this and take an example-based tests approach for any non-trivial DBT models: https://github.com/EqualExperts/dbt-unit-testing More trivial example: {% call dbt_unit_testing.test( 'REDACTED', 'Should replace nullish values with NULL' ) %} {% call dbt_unit_testing.mock_source('REDACTED', 'REDACTED', opts) %} "id" | "industry" 1 | 'A' 2 | 'B' 3 | '' 4 | 'Other' 5 | 'C' 6 | NULL {% endcall %} {% call dbt_unit_testing.expect(opts) %} "history_id" | "REDACTED" 1 | 'A' 2 | 'B' 3 | NULL 4 | NULL 5 | 'C' 6 | NULL

> How do you test some SQL logic in isolation? I do this using sql 1. Extracting an 'ephemeral model' to different model file 2. Mock out this model in upstream model in unit tests https://github.com/EqualExperts/dbt-unit-testing 3. Write unit tests for this model. This is not different than regular software development in a language like java. I would argue its even better better because unit tests are always in tabular format and pretty easy to understand. Java unit tests on other hand are never read by devs in practice. > in this day and age where enriching the data by running it through some ML model isn't that rare, Still pretty rare, This constitutes a very minor percentage of ETL in an typical enterprise.

Sure a full fledged programming stack will obviously have a more mature tdd facilities. this if you choose to write sql . sql vs spark is probably a discussion for another time :0 > This just looks like a messier, more unclear way to test some SQL. As a software engineer I've written my own share of unit tests. They are supposed to be documentation of how a unit might work but it rarely ever works in that way. I found that to be more true for CSV tests for sql https://github.com/EqualExperts/dbt-unit-testing#different-w... because they are always in the same format , input csv -> output csv I am more motivated to look at the tests to see what sql is doing. Its pretty straight forward.

> I really don’t understand the communities obsession with unwieldy tools like DBT. It lets me write test first sql transforms. I never thought TDD sql would be possible. My sql is so much more readable with common logic extracted into ephmeral models. I practice same method to write clear code to write sql, eg: too many mocks = refactor into separate model ( class) . I think DBT made this possible with refs that can be swapped out with mocks. This is the awesome library I am using https://github.com/EqualExperts/dbt-unit-testing