4 ms·

> just aim for 100% test coverage instead (with excluding some categories of files). That's where the 'gaming' comes in. The tests start just going through l

> just aim for 100% test coverage instead (with excluding some categories of files). That's where the 'gaming' comes in. The tests start just going through lines without hitting a single expect statement. The ignore files start becoming battlegrounds in the PRs because people just exclude half the damn project. We just have a simple rule... if you wrote code, you have to write coverage for it. If it breaks and your test doesn't catch the breakage, the bug fix goes back to you. Some people will ask "but what about what I'm working on now", you'll have to communicate that you feel your previous work was far more important.

deleuze 6y ago
> the bug fix goes back to you. Some people will ask "but what about what I'm working on now", you'll have to communicate that you feel your previous work was far more important. this feels punitive, especially in the eyes of management. unless you're in a safety critical area where fully testing every code path is a hard requirement, people will eventually write bugs. i'd rather work somewhere that recognizes defects occur and has a fast iterative process to push out new changes rather than one based on shame for having written a bug.
- WrtCdEvrydy 6y ago
  > has a fast iterative process to push out new changes rather than one based on shame for having written a bug. That is the fastest most iterative process we have found so far... as the expert on the original code, you are able to deliver the best outcome. You're not being shamed for writing a bug, you're being shamed for not testing your code.