3 ms·
> In my own experience, post-facto automated testing just locks in the codebase to behave exactly as it did before the tests That's a great starting point for
by The_Colonel 3y ago
> In my own experience, post-facto automated testing just locks in the codebase to behave exactly as it did before the tests
That's a great starting point for refactoring or just normal feature development. You need the confidence that your changes won't break the system in unforeseen ways.
- cybrox 3y agoYes, I (as well as the commenter above, I assume) just doubt that the sheer number of tests will do this in a useful manner. If you have a giant bunch of code that has been written without testability in mind, adding tons of tests mostly just locks down the interfaces of every single segment of code, making refactoring really hard to a point where the tests are useless because they have to be rewritten as well anyways. Good test are written for good code that is written with testability in mind. In that case, only the relevant interfaces are proplery tested and not every little internal thing, which allows for proper refactoring and expansion without fiddling with the tests. This however also yields a lot fewer tests, which is why I doubt this large number of tests can be high quality and/or beneficial.
- et1337 3y agoI tend to agree with you, although I'd say most of the tests are pretty "high quality" (for the most part they don't rely on global state and they run in parallel, randomized order). You pretty much perfectly described our current situation. There is a push to crystallize everything down to the last function. It's not uncommon to have one change result in hundreds of test failures.