>>This might be our disagreement -- this is IMO outdated terminology,
It really isn't. The concept of integration tests, and the test pyramid, is not only the standard practice but also basic concepts that somehow some developers struggle to understand and use.
> and in my experience not modern practice.
That could only start to make sense if modern practices consisted of screwing up their test plans and fail to do any form of test on how different components integrate.
I assure you that that is not the standard practice in any competent shop, big or small.
> It's super easy now-days to swap in a local lightweight database like sqlite which is 99.9% compatible with your production database, and use this for even tiny unit tests.
You're just stating that it's super easy to screw up badly by not knowing what you are doing. And I agree.
Take a step back and read what you're saying. You're replacing an external service accessed over a network by multiple clients with an internal service running in the same process that only your app accesses, generating entirely different databases and SQL, seed the database with between none and almost no data, and then run a few isolated tests.
And somehow this makes you believe you're testing how your system integrates?
I mean, even if you use frameworks with support for code-first persistence models you should be aware that different databases are generated by different targets. Take for example ASP.NET Core's Entity Framework Core, which notoriously fails to impose constrains with jts sqlite driver.
How, pray tell, do you believe your tests are meaningful if you're not even testing a system with the same topology, let alone the system you expect to put in production ?
This is by no means "modern". This is outright wrong on so many levels, including the mental model of how the system operates.
If you're really interested in best practices and how to do an adequate job testing your stuff, you should be aware that every single test beyond unit tests is supposed to be performed on the application intended to be deployed to production. The application is built and packaged after conducting unit tests, and that same package passes.through a whole obstacle course until it reaches production. It makes sense if you start to think about it. I mean, isn't the whole point of testing that you ensure that the app you want to run in production, and not a variant of it or a different build, runs as expected?