dbt-unit-testing VS enso

If you use dbt for transformations Dbt Unit Testing (https://github.com/EqualExperts/dbt-unit-testing) is getting some attention (https://www.thoughtworks.com/radar/languages-and-frameworks?blipid=202304042)

dbt-unit-testing

We use this and take an example-based tests approach for any non-trivial tables: https://github.com/EqualExperts/dbt-unit-testing

> 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.

I haven't done it yet but there are some popular blogs as well as a DBT package someone created.

> 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

> At least I have yet to see one that is actually useful in the sense of a generic (or even a single-purpose-built) language

Yeah as said, https://github.com/enso-org/enso seems to be a general purpose functional programming language with visual editor, but otherwise I haven't really seen any no-code solutions worth their salt. I'm not particularly a fan of enso either, but it's the best I've seen.

Although it's not quite the same, I do like what Enso[0] is bringing to the table, especially the 1:1 visual node/language interop. Whether this is generalisable to a fully decoupled interface remains to be seen, but there's definitely potential.

[0]: https://enso.org/

I think Enso is already taken by a YC company [0]. Could get confusing.

[0] https://enso.org

COMPANY: Enso Inc. TYPE: Full time LOCATION: Europe and United States of America – fully distributed company REMOTE: Only remote VISA: No VISA required DESCRIPTION: Hi, we are Enso (enso.org, Y Combinator S21)! We are looking for an amazing Cloud engineer to join our core team. We are a remote first company, working in Europe and the USA.

Friends of mine are developing Enso (https://enso.org/), an interactive programming language with dual visual and textual representations.

Even well before Bret Victor's time, there were tools for visual programming. I have been using LabView to maintain data processing in an optical laboratory.

> I'm convinced this entire space should be visual.

At my last 2 jobs I spent entirely too much time debugging Matillion jobs, which are visual. I have my doubts that it’s the panacea that it appears to be.

That said, you may find Enso particularly interesting: https://github.com/enso-org/enso