Tactics for dbt tests running on views

Help
, ,
1

The problem I’m having

Tests in our data warehouse take a lot of time. I discovered that it models materialized as views take a long time to be tested.
I assume that for each test all the data must be collected. When I have 50 tests on one view, it takes a lot of resources.

What I’ve already tried

I know I can skip all the tests on views and create a separate layer of tables where those tests will be applied.
select * from my_view_with_no_tests
But It’s not a great solution. It adds complexity to our project and hundreds of tables are created.

I think about solution like this:
Whenever I need to test any view, I create a temporary table. I run all the necessary tests on it and then I drop it.

I think someone experienced this kind of problem already and I hope you may give me some advice.
Thank you!

2

Your solutions to this problem seem pretty strange to me. I would start by going back to first principles: why are these views, rather than tables? What do you gain from them being views?

If you’re going to make tables anyway (downstream tables to run tests against, or temp tables you’re planning to drop), why not just make the views into tables and cut out the middleman?

Expensive tests against views is often the most compelling argument for not using a view. You can either move the tests somewhere else in the DAG that makes sense - don’t create new table nodes just to test, but if a node already exists that would be suitable to test - or you can make these views into tables. Those are the two basic options.

Note: @Mike Stanley originally posted this reply in Slack. It might not have transferred perfectly.