> So in my opinion, the primary purpose of automated tests is not to avoid failures, but to speed up development. Such a juicy premise, let's dig in. In my opi

> So in my opinion, the primary purpose of automated tests is not to avoid failures, but to speed up development. Such a juicy premise, let's dig in. In my opinion the primary "speed up" to development comes in allowing changes - especially sweeping refactors - to happen without worry. As a corollary, they provide "primary source documentation" on the inner workings of the code so that less-experienced developers can approach such tasks without worry. The value of these are exactly the same regardless if your tests take 10 seconds or 10 minutes to run. The only difference is that we've sped up our critical path development work by not focusing on hyper-optimizing tests. And to start out the gate with such a premise but then fail to provide any data related to the effects on developer cadence, in a data-heavy writeup!?