4 ms·
> If you want to reduce your test mass, the number one thing you should do is look at the tests that have never failed in a year and consider throwing them awa
by chillacy 10y ago
> If you want to reduce your test mass, the number one
thing you should do is look at the tests that have never
failed in a year and consider throwing them away
And that's how you get regressions. I get the rationale that these tests cover code which probably never changes, and tests are most useful for code that changes a lot. But if the guy who wrote the code left the company a year ago and then you have to change this code... it's going to be a lot easier if there are good tests.
- arthur_pryor 10y agoalso, how do you know a test didn't fail locally on a developer's machine, causing them to fix work in progress? IME, test failures are only tracked on dev/stage/prod deployed systems.
- jernfrost 10y agoHe did cover that. He said specifically that regressions tests are a good thing, but that they are typically not done at the unit level.
- sv123 10y agoHe means that's how you get regressions of the same bugs popping up in the future, not regression tests.
- rst 10y agoNot at all sure how anyone following this advice with, say, a Rails app ever upgrades to a newer version of the framework. When the framework APIs change, you need something exercising the code just to verify that it interoperates with the new versions. (Yes, apps and frameworks based on a statically type-checked language would catch some of these cases. But not the ones that change behavior of something while leaving the relevant type signatures intact.)