Hi! I’ve pondered the same questions.
A Google article implied they tag their tests as one of Small, Medium, or Large: “The engineer chooses the size when they initially write the test, and the size is not always updated as the test changes.”
Tagging seems like a sensible approach. I suppose a sophisticated solution could automatically measure and assess test types (e.g. does it use a network? does it use a database?). Test nuances could make that tricky.
For years I’ve been a strong follower of Martin Fowler’s microservice test pyramid which includes five layers. Lately I’ve been questioning this approach as I’m not sure anymore if the triangle applies to all software projects. (Obviously Fowler designed his pyramid for microservices and services, not monoliths, although some principles apply to both.) Kent C Dodds, for example, has found a slightly modified approach that works well for him. (I would link it here but I’m a new user and “new users can only use two links on posts” for some reason.)
When it comes to functional testing (does it work the way I think it does?), I find myself leaning more toward a diamond than a pyramid, striking the balance between mock-all-the-things unit testing (reliable, low $$ cost, little value to end user) and mock-zero-things end-to-end testing (less reliable, high $$ cost, high value to end user). In the middle, where integration and contract testing happens, I get a relatively high confidence of release without sacrificing test reliability or having to pay more $$ and maintenance.
I still use end-to-end tests on deployed environments for Continuous Verification after deployments, and I still use unit tests for tricky methods/functions, but I validate most of my business logic and service contracts with the integration/contract tests. Thus I end up with a diamond.
Just my thoughts. I’m still learning.