4 ms·

Sadly, writing tests to have tests is totally a thing. A tech lead can come in a new team and ask for 80% or more of code coverage and no one will bat an eye. W

Sadly, writing tests to have tests is totally a thing. A tech lead can come in a new team and ask for 80% or more of code coverage and no one will bat an eye. Will the software work better for it ? that's up to debate and it will depend on the quality of the tests. I get your point of view, it feels completely absurd. The same way writing JIRA tickets just to have tickets, writing dumb comments because the CI will yet at you for not having comments frel absurd. And it's a reality in more places that I wish. > And we continue: it’s not about software that is useful for the user; it’s about software that is useful for the business. If we look at the number of failed businesses, that's a lesson that needs to be relearned again and again.

keybored 3y ago
> Sadly, writing tests to have tests is totally a thing. A tech lead can come in a new team and ask for 80% or more of code coverage and no one will bat an eye. Will the software work better for it ? that's up to debate and it will depend on the quality of the tests. This is true but not the bad faith part. The bad faith part is assuming—based on nothing—that the other interlocutor is doing thing because of cargo-cult/silly reasons.
epgui 3y ago
I completely take your point and agree with you. I’d just like to add a nuance/complication: sometimes it makes perfect sense for a lead to come and insist on the test coverage metric hitting X%. Not because it’s a good idea on its own or in general, but probably because of very context-specific reasons. It’s not uncommon for engineers to not think about how their code tests at all (which is related to the interfaces they design), so something as arbitrary as this can be a forcing function to bring a baseline of awareness and competence to a team. In that sort of scenario, ideally the norms change as the team problems evolve, and so that arbitrary test coverage goal would ideally become irrelevant over time as a team improves and matures. Think back to your first weeks / months of programming: this sort of reductionist and over-simplistic “rule” was probably very formative in your early years, even if you had to unlearn them over time. Real teams have people with a spectrum of skills, and sometimes you have to set crazy-ish rules to level-up the baseline.
- deleted 3y ago
  [deleted]

keybored 3y ago

> Sadly, writing tests to have tests is totally a thing. A tech lead can come in a new team and ask for 80% or more of code coverage and no one will bat an eye. Will the software work better for it ? that's up to debate and it will depend on the quality of the tests. This is true but not the bad faith part. The bad faith part is assuming—based on nothing—that the other interlocutor is doing thing because of cargo-cult/silly reasons.

epgui 3y ago

I completely take your point and agree with you. I’d just like to add a nuance/complication: sometimes it makes perfect sense for a lead to come and insist on the test coverage metric hitting X%. Not because it’s a good idea on its own or in general, but probably because of very context-specific reasons. It’s not uncommon for engineers to not think about how their code tests at all (which is related to the interfaces they design), so something as arbitrary as this can be a forcing function to bring a baseline of awareness and competence to a team. In that sort of scenario, ideally the norms change as the team problems evolve, and so that arbitrary test coverage goal would ideally become irrelevant over time as a team improves and matures. Think back to your first weeks / months of programming: this sort of reductionist and over-simplistic “rule” was probably very formative in your early years, even if you had to unlearn them over time. Real teams have people with a spectrum of skills, and sometimes you have to set crazy-ish rules to level-up the baseline.

deleted 3y ago
[deleted]