Technically these issues are solved with what I indicated is always missing: time. What you outlined is accurate: proper testing also requires proper planning f

Technically these issues are solved with what I indicated is always missing: time. What you outlined is accurate: proper testing also requires proper planning for tests. For more complicate projects, you don't just start writing them without mapping out everything that needs to be done - and how to go about it. And yes, when code changes, more time must be invested into refactoring the tests. This disastrous ecosystem exists with QA too (which is again, a form of testing). A lot of companies - usually the smaller ones - don't invest any resources at all for QA. Others just do point-and-click smokescreen tests that'll discover bugs that are blatantly obvious (also typically the ones the developer should never have committed to begin with). Real, proper QA? That requires investing serious time into test cases - completely figuring out every possible interaction and scenario that can take place. All before a single actual test is run. And similar to unit/functional tests, QA test cases need to be reviewed whenever the smallest bit of functionality changes. The reality is that most employers who "want test cases" want there to be a magical solution that gives all the benefits, without any effort.