steve 12 December 2016 This is interesting: “Recently, the startup I was a part of had to remove large sections of our website. Not just content, but entire pages and functionality. It wasn’t a very pleasant experience, not only for the reason why we had to remove so much of what we had built, but also because it’s the ultimate “I really hope this doesn’t break something else” situation. It was a stressful and tedious effort of triple checking that the things we were removing weren’t dependencies elsewhere. To be honest, we wouldn’t have been able to do this with any amount of success or confidence without our test suite.” I agree that having automated tests in place is valuable and can give confidence when making any changes to an existing application, however what you choose to test and how you test it will determine how scalable your test writing process is. Its important when adding any features to your process, including the testing, that it is well thought out, and provided in a way that is easy to create, read, update, delete just as much as the code is, or you can have an expensive, or slow build process. It is also important to have been in a bad code environment or a bad test environment, and experience the difficulty of it, so it can motivate change for improving the process, and influence better technology stack decisions, not just popular ones.