Thanks for this write-up! The article describes well the up- and downsides of browser-based E2E tests on the one side and unit tests on the other side. However, it would be wrong to assume that these are the only types of automatic tests. Another one type that comes into my mind are tests that I'd call API-E2E tests: They for example call an API endpoint of the backend (dev or stage server) and check for its response. Or, in case of a library that is to be tested, they call public (main) methods and check for the return values. Those come probably very close to the advantages of unit tests. With API-E2E tests, you can have the advantages of both worlds: these tests are much faster than browser-based E2E tests, as they don't need a browser there is also not much of additional setup needed, as you have (or should have) anyway a stage or dev server to be set up these tests are robust even if your inner architecture changes and e.g. you redesign your class and methods' architecture Especially the latter makes me skeptical about unit tests because they basically force you to double your code: You not only have to write a new function but also a test for a new function. Or if you want to rename a function, you need to do it at least twice: in both the test and the code (unless your IDE is smart enough to recognize the matching test) Yes, I do understand that this extra code is meant to be a feature, not a bug, as it automatically gives you a specification and documentation – yet even you seem to agree that this slows down development ("instead of moving fast and break things, I aim to move slow ..."). Further remarks: I maintain a suite of 3200 unit tests that run in about 30 seconds—only about 1/100 of a second for a test. True, but when comparing the number of unit tests with the number of E2E tests, we have to remember that 1 E2E tests usually covers a lot of methods, whereas a unit tests usually covers only one method.