Hacker News Reader

I meant upgrading application frameworks, OS, etc., so it’s not a red herring. Those can inflict a lot of changes if you have a lot of tests affected.

View on HN

Thus automated test time + automated test maintenance is usually less than manual test time + manual test maintenance. Mostly because execution time for automated tests is so much shorter than manual execution time that the higher cost of automated test maintenance is recouped and then some.

The only way for framework\OS changes to impact that is if they happen often enough to make automated test maintenance "weigh" more than all the time saved by no longer having to manually run your test suite.

I don’t think we’re speaking the same language. I’m talking about how much time it takes to change the code in every unit test, etc. because you upgraded something that requires changing the test framework, and this library and that one, so you end up not only having to fix all of your production code, but all of the tests with their mocks, stubs, injections, annotations, xml config, etc. If you have thousands of tests, this can keep people from upgrading.

Reply on news.ycombinator.com