This separation between unit and integration became vague nowadays.
Instead we can think in term of purity and extent.
Purity → "corresponds to the amount of generalized IO the test is doing and is correlated with desirable metrics, namely performance and resilience."
Extent → "corresponds to the amount of code the test exercises. Extent somewhat correlates with impurity, but generally does not directly affect performance."
Unit > Integration > E2E is still a valid pyramid for testing; but better can be found.
Static analysis > Unit + Integration > e2e
Unit and integration tests are mixed together as:
The definition of a unit is often “to be discussed”: If you ask a group of developers to define a unit, you will mostly get various, differing answers. As some refer to a function, class, or service — minor units — another developer will count in the complete component.
In addition to those definition struggles, drawing a line between unit and integration can be tricky, as it’s very blurry. This struggle is real, especially for Frontend, as we often need the DOM to validate the test basis successfully.
It’s usually possible to use the same tools and libraries to write both integration tests. So, we might be able to save resources by merging them.
There are also visual tests. We can group e2e-tests and visual tests into a UI test category. Btw the recommended open-source and fully self-hosted tool for visual testing is Visual Regression Tracker
Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists. Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example). Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent. Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.