> In truth the best way to do the data layer is to use stored procs with a generated binding at the application layer. This is absolutely safe from injection, and is wicked fast as well.
[Who must keep stored procedures in sync with migrations,]
1. Almost nobody in the team knows SQL, stored procedures more so.
2. It's not possible to deploy and test stored procedures with the usual tooling. Actually I don't know what's the usual way to do it in projects that go with that approach.
I don't really understand the confusion here, you write a stored procedure, you document it, test it, peer review it, then stuff it into the database. You then write code that uses it. No sarcasm, but what's the problem?
I think they're referring to ongoing automated tests, and not one-off tests.
That works; it's just maybe thousands of times slower than unit tests, and much more work to create and maintain.