That's your business logic in the database right there.

So no, you don't get to wiggle out of that one.

Unit testing PL/pgSQL is nasty.

But unit testing is not nasty at all: just look up pgTAP.

What's nasty is that the incumbent development model intersperses data modelling constraints in the database and in the non-db code, and then we test one layer implicitly from another layer.

You'd usually have backend code guarding against constraint-violating entries, and then you'd have a database constraint too.

So what you need to do now is test almost exactly the same thing from your code test and from your database test to get proper coverage.

Enter declarative ORM schemas, and suddenly there's not even a guarantee that the schema you are running really matches what your ORM thinks the schema is.

For that reason, I prefer all those SQL-based database migration/evolution approaches over ORM-based schema generation, coupled with pure SQL tests (eg. with pgTAP, but yeah, any tool can do).

Basically, even for declarative code, there should be a unit test, a la double-entry bookkeeping in accounting.

And even if this is what I prefer and believe is only right, I never worked on a large company project that did all of these things.

So I don't think the entire topic should be easily dismissed: while unit testing is simple, have you ever worked on a project that tested db-schema embedded logic exactly at the right level (and not the level up)?