>They tend to be small according to Google’s definitions of test size. Small tests are fast and deterministic, allowing developers to run them frequently as pa

>They tend to be small according to Google’s definitions of test size. Small tests are fast and deterministic, allowing developers to run them frequently as part of their workflow and get immediate feedback. Yes, but for companies that are not Google scale, it should be possible to run end-to-end tests fast without too much trouble. >They tend to be easy to write at the same time as the code they’re testing, allowing engineers to focus their tests on the code they’re working on without having to set up and understand a larger system. But tests maybe should not be easy to write at the same time as the code they're testing, that implies too tight coupling between code and tests. >They promote high levels of test coverage because they are quick and easy to write. High test coverage allows engineers to make changes with confidence that they aren’t breaking anything. Why would a good end-to-end test be harder to write than 100 unit tests that purport to cover the same code paths? >They tend to make it easy to understand what’s wrong when they fail because each test is conceptually simple and focused on a particular part of the system." A good end-to-end test will give you the same thing if the code logs errors well. And if it does, that will be good for you even in production, not just testing. >They can serve as documentation and examples, showing engineers how to use the part of the system being tested and how that system is intended to work. I can see the value of this, but in practice I think that it is usually hard to show engineers how to use some unit without them being aware of the larger system.