Thank you for a great article. I am going to share with my teams to read this post and discuss. As you mentioned the lack of testing and the rigor that is required to Test is not just technical —it’s human. Organizations and engineering teams should focus on identifying areas that introduce friction for the engineers and reduce or eliminate need for Engineers to cut corners. Additionally, embedding and exposing the engineers that build software/data pipelines to be exposed to the operational issues often and early will make them realize the risks of missing Testing. Shift left as much as possible and invest in improving DevEx.
Tests can do more than prove that things don't break. Particularly with a DSL like Gherkin, you can wield them as a form of living specification and documentation for a system, offering value not just for developers or QAs but also anyone who wants to understand something at a high-level.
Also, knowing what (and when) to test is a subjective art. I find tests helpful to describe complex systems that aren't self-descriptive in code, and also a helpful way to lay out business logic requirements before actually trying to implement them. I no longer die on the 100% coverage hill, but also think the lack of tests in certain places can be confidence-sapping.
This has to be one of the best articles I've read this year! Going to request my entire team (and upper management) read it. Thanks!
Thank you for a great article. I am going to share with my teams to read this post and discuss. As you mentioned the lack of testing and the rigor that is required to Test is not just technical —it’s human. Organizations and engineering teams should focus on identifying areas that introduce friction for the engineers and reduce or eliminate need for Engineers to cut corners. Additionally, embedding and exposing the engineers that build software/data pipelines to be exposed to the operational issues often and early will make them realize the risks of missing Testing. Shift left as much as possible and invest in improving DevEx.
Tests can do more than prove that things don't break. Particularly with a DSL like Gherkin, you can wield them as a form of living specification and documentation for a system, offering value not just for developers or QAs but also anyone who wants to understand something at a high-level.
Also, knowing what (and when) to test is a subjective art. I find tests helpful to describe complex systems that aren't self-descriptive in code, and also a helpful way to lay out business logic requirements before actually trying to implement them. I no longer die on the 100% coverage hill, but also think the lack of tests in certain places can be confidence-sapping.