3 ms·

> ed. note, wow you added a lot as I was typing out my response to this I only spend, like, two minutes editing a comment after I post. You must have had a sta

> ed. note, wow you added a lot as I was typing out my response to this I only spend, like, two minutes editing a comment after I post. You must have had a stale browser window open. > If you're finding bugs in code that isn't covered by tests, I'd take that as evidence that your coverage isn't sufficient. That's an extremist viewpoint. It's unreasonable. It's a waste of time and money. You have tons of tools at your disposal for finding bugs in your code. You have automated tests, manual tests, unit tests, integration tests, type systems, static analyzers, linters, code review, logging, analytics, and bug reports from production. Use a mixture. As you increase the sensitivity of any one tool, the cost of development increases. For most projects, if you don't see bugs in production, you are not shipping soon enough. The cost of shipping late is, at some point, going to be larger than the cost of shipping bugs to production. > In some codebases, 100% test coverage is equivalent to solving the Halting Problem. Don't sweat it. My experience is that there are only a few explanations for why you would see a code base with 100% test coverage: 1. The code is so critical that high test coverage is justified (e.g. SQLite), 2. The code is so trivial that high test coverage is easy, or 3. The engineers in charge are just fucking nuts. I'd like to share this recent quote from @tef_ebooks: https://twitter.com/tef_ebooks/status/1434706902366228480 https://twitter.com/tef_ebooks/status/1434706902366228480 > trying to work out how to impress on people that i'm an incredibly masculine programmer, and although people have suggested comparing it to hunting animals for food, as far as i can tell the most 10x macho behaviour that programmers do is working unpaid overtime > the best thing about being a macho programmer is that you can do it by saying one thing like "write 100% test coverage" or the opposite "i don't write tests" because nothing shouts status like extreme viewpoints in a land of tradeoffs

klyrs 5y ago
You seem to have assumed that I'm a 100% test coverage no matter the context or costs person, and ran with that. I hope you've enjoyed fighting that person, but that's not me. Have a nice day. edit: I feel like I should remind you that I responded only to the first 2 paragraphs of that comment I'd quoted. I wasn't trying to shame you for editing your comment or anything, just trying to clarify what I was responding to.
- deleted 5y ago
  [deleted]
- klodolph 5y ago
  > You seem to have assumed that I'm a 100% test coverage no matter the context or costs person, and ran with that. I was talking about using type annotations to catch "simple typos in code paths that are not exercised in tests." Those are the exact words I used. And you responded, first explaining how to catch those bugs with tests, or how the existence of these bugs is a signal that your tests should be better. Like, I just don't get what you are trying to say. If you accept that your code doesn't have 100% test coverage, then you accept that there will be bugs in untested code paths that are not caught by your tests. But you said that you "take that as evidence that your coverage isn't sufficient." As far as I can tell, that means you're aiming for 100% test coverage or somewhere close.

klyrs 5y ago

You seem to have assumed that I'm a 100% test coverage no matter the context or costs person, and ran with that. I hope you've enjoyed fighting that person, but that's not me. Have a nice day. edit: I feel like I should remind you that I responded only to the first 2 paragraphs of that comment I'd quoted. I wasn't trying to shame you for editing your comment or anything, just trying to clarify what I was responding to.

deleted 5y ago
[deleted]
klodolph 5y ago
> You seem to have assumed that I'm a 100% test coverage no matter the context or costs person, and ran with that. I was talking about using type annotations to catch "simple typos in code paths that are not exercised in tests." Those are the exact words I used. And you responded, first explaining how to catch those bugs with tests, or how the existence of these bugs is a signal that your tests should be better. Like, I just don't get what you are trying to say. If you accept that your code doesn't have 100% test coverage, then you accept that there will be bugs in untested code paths that are not caught by your tests. But you said that you "take that as evidence that your coverage isn't sufficient." As far as I can tell, that means you're aiming for 100% test coverage or somewhere close.