3 ms·

I can definitely sympathise with the SQL developers here. (I have worked extensively both with SQL and C++). There is a trade off between unit tests and having

I can definitely sympathise with the SQL developers here. (I have worked extensively both with SQL and C++). There is a trade off between unit tests and having control and overview of what you are writing. Also very often it is so much more about verifying that the input data is clean and if this becomes more cumbersome, you may have lost the ability to debug the biggest source of errors. And of course sometimes it hits a nerve when the "real engineers" come and dictate exactly how you should do things. Reference also to Joel Spolsky's architecture astronauts.

NortySpock 2y ago
dbt v1.8 added a feature to be able to unit-test a view or CTAS statement. (a natural extension of dbt since it was designed to assist with moving and renaming the inputs to a view) I haven't tried it yet but I look forward to doing so. Already dbt macro expansions with tests have provided me way more test coverage than I ever had in the pre-dbt days. It's a footnote in the article, but it seemed like a natural half-step forward in the direction indicated by the article.