3 ms·

True; but you're going to get much better testing if your team collectively cares about it than if it feels externally mandated by that one annoying guy who set

True; but you're going to get much better testing if your team collectively cares about it than if it feels externally mandated by that one annoying guy who set up your commit rules. Technical solutions are the best solutions when they work. But being technologists will bias us towards looking for technological ways to solve problems. Its not always the best approach. A few hours chatting over lunch is usually a much more effective way to change how your team works.

wpietri 4y ago
> True; but you're going to get much better testing if your team collectively cares about it than if it feels externally mandated by that one annoying guy who set up your commit rules. Some of the worst tests I've ever seen were in places where managers measured test coverage. Reams and reams of absolutely useless tests that may not have checked anything that mattered, but that did bump the coverage metric up.
- quanticle 4y ago
  Reams and reams of absolutely useless tests that may not have checked anything that mattered, but that did bump the coverage metric up. I would go farther than that, and call those tests worse than useless. Tests that are written to appease some kind of automated coverage metric god tend to be tests that test internal implementations rather than API contracts. So you end up with a codebase where a single line change to production code requires something like 150 lines of test code changes, all because the internal representation of some data was changed in some kind of trivial way. It's possible to avoid this failure mode, but the teams that are smart enough to avoid this failure mode are also generally smart enough to avoid having unreasonable coverage goals.
- F-W-M 4y ago
  I once found ``` if (var) assert(var) else assert(!var) ``` in the outsourced test suite for a level A air plane software.
eru 4y ago
Agreed. I am suggesting that the technical environment can make certain cultures mores easier or harder to do. Cultural change is hard enough, so getting as many of the technical nudges as you can, is good.

wpietri 4y ago

> True; but you're going to get much better testing if your team collectively cares about it than if it feels externally mandated by that one annoying guy who set up your commit rules. Some of the worst tests I've ever seen were in places where managers measured test coverage. Reams and reams of absolutely useless tests that may not have checked anything that mattered, but that did bump the coverage metric up.

quanticle 4y ago
Reams and reams of absolutely useless tests that may not have checked anything that mattered, but that did bump the coverage metric up. I would go farther than that, and call those tests worse than useless. Tests that are written to appease some kind of automated coverage metric god tend to be tests that test internal implementations rather than API contracts. So you end up with a codebase where a single line change to production code requires something like 150 lines of test code changes, all because the internal representation of some data was changed in some kind of trivial way. It's possible to avoid this failure mode, but the teams that are smart enough to avoid this failure mode are also generally smart enough to avoid having unreasonable coverage goals.
F-W-M 4y ago
I once found ``` if (var) assert(var) else assert(!var) ``` in the outsourced test suite for a level A air plane software.

eru 4y ago

Agreed. I am suggesting that the technical environment can make certain cultures mores easier or harder to do. Cultural change is hard enough, so getting as many of the technical nudges as you can, is good.