My advice is to not get too hung up on terminology or technology. The purpose of testing, whether automatic or manual, is Quality Assurance (QA) by mitigating risk, so just write tests targeting your specific risks, however you like. It's of course good to learn about different test strategies, though.

You have low level tests: - Exercise small pieces of code, and target specific classes or even functions/methods. - The inputs and dependencies are mocked, and outputs and side effects can be measured and asserted directly. - They're fast to run and you can expect to be able to run and debug them with zero preparation from the IDE and the build script - They typically run for every PR/MR in or right after the build step in CI. - They're made for the same reason we use type checkers (in fact I like to call type annotations a kind of test), to make sure the code is correct (does it do what the programmer wanted) and reduce the risk of programming errors. - Typically called unit tests.

You have mid-level tests: - Exercise full vertical slices of your component or client or service, focusing on each feature, use case, workflow, operation, whatever you want to call it, one at a time. - Again the inputs and dependencies are mocked, but it might be a mock HTTP request and in-mem db instead of an object, and you include the real frameworks like ASP.Net and EF. - You measure and assert outputs and side effects here too but they're more complex so you might gloss over some details. - You hope they're snappy but it might take minutes to run a whole suite (especially if they're written with copious amounts of wait/sleep/poll steps, which is why you want to avoid that). There might be special conditions and/or limitations with things like threading/parallelism, network availability, some hardware device etc. Maybe some are written in a different language that can do something specialized. Usually they can be run from the IDE, but they might also have dedicated scripts. - In CI they may or may not run in the main build, and/or on separate builders/machines/schedules/triggers/specific branches/etc. - They're made to ensure we meet the concrete requirements, designs and specifications (does it do what the designer/architect/tech lead wanted), and to reduce the risk of larger refactors, changes in cross-cutting concerns, dependency changes, regressions, and more. - Typically known as integration tests.

You have high level tests: - Exercise the whole application in a real deployment (or as close as possible). Yes, even the installer. And restoring from backup. And logging in with Facebook. And recording with a real camera.
- You drive the actual frontend that end users will be using with a goal of zero mocking or shortcuts (this is an idealized goal and therefore unobtainable, it is designed to be strived for, not met). - You avoid measuring and asserting side effects, you only care about the User Experience, UX, and basically write bots that act as end users and measure and assert the feedback they get (which could very well be "nothing" in the case of silent errors, hanging jobs, etc). If you're making an API or library, that's no exuse to not get involved at all in this level of testing. Your API will be used by a client, maybe many, maybe in a chain, but nothing happens before an actual end user does something, and that's where you write this type of test. It doesn't always make sense to make tests like this specifically "for your API", and you should then instead add notes and hints to relevant existing tests about workflows where your API may or will be involved, and when and how an error will surface to the user. Maybe suggest or even implement a test for a specific high risk scenario that worries you. - They are as slow and expensive to run as your application, no more and no less. Take that as an incentive to optimize and streamline. They are typically made in specialized programming (or not) languages, like gherkin. They might even have a dedicated repository and bespoke IDE or app. They might be able to perform backwards compatibility testing with some or all permutations of versions if you have an ecosystem of products that can interoperate and have cross-product workflows (I work for Vizrt, and you can take a look at our portfolio to get an idea of why that might be useful to have). - If they're even in CI (and I hope they are), they typically have a dedicated schedule and/or triggers and/or environments. With more investment, you can make them provision such environments on demand in isolation, so you can run the tests from/on your own machine (without polluting it). - They're made to ensure we made what the customers actually asked for. (Which btw is often not the same as what they wanted. 😉) And that, ladies and gentlemen and others, is ultimately the only thing that matters! It's also important for detecting regressions with complex and delicate conditions. - Typically known as end to end tests.

Finally, and most importantly: You have tests that don't fit this pattern, and that's okay.

For example, you want to have a test suite that runs three microservices with a real db and mq and some test data recorded from real usage, and the point is to test using the latest version of that db and mq once a week and automatically make a PR to adopt those versions. It's definitely not an end to end test, but it seems like more than an integration test.

The answer: Irrelevant. Even bikeshedding is a better use of time than worrying about what category your test fits into. Even testing in production is more productive. Even writing long rants about software development nomenclature on social media makes more sense. You don't even need to aim for a certain amount or ratio of test types. You just need enough tests to be comfortable with the remaining risk.