Tests applied to models

[cbeiro]

Hi!

Thanks for developing this package.

Is it possible to take into account tests that are applied to models and not only to columns? For example https://github.com/dbt-labs/dbt-utils#equal_rowcount-source or the tests created by https://github.com/mjirv/dbt-datamocktool.

Thanks!

[sweco]

Hey @cbeiro! 😊 We're glad that you like dbt-coverage!

We were indeed thinking about adding table-level coverage (both docs and test) but haven't had time to do so yet. One possibility of doing so would be to just mix the table-level coverage in between the columns but I guess ideally we would allow selecting between table-level, column-level, or mixed coverage, which would require a bit more work.

What do you think about the approaches?

[aranke]

Another approach I considered for a similar project was creating a boolean column to indicate whether the table had coverage.

Could probably use true/false for JSON and ✅/❌ for the console output.

The reasoning behind this approach is that the denominator of the table-level coverage will always be 1.

[sweco]

You're right @k-aranke, the denominator would always be 1. With the table-level coverage, the most interesting would be the totals as they would show the percentage of tables covered.

As for what I see as the easiest implementation of the table-level coverage is to automatically generate an imaginary column called for example <table> for every table and use it to reflect whether the table is covered with table-level docs or tests. The report would then look like this:

=========================================================================
- jaffle_shop.customers          -/-       (-)    ->     6/8    (75.00%) 
-- <table>                       -/-       (-)    ->     0/1     (0.00%) 
-- new_col                       -/-       (-)    ->     0/1     (0.00%) 
=========================================================================

On the other hand, I'm not sure this helps much for the tests because based on my knowledge, people usually only aim to cover very few columns with tests (IDs, maybe FKs) and they are not interested in the coverage of the other ones. Therefore, they are mostly after knowing whether there is at least one column covered with tests per table.