3 ms·

I do test exceptions, I just don't test 100% of code paths. Do you encourage 100% code coverage? Because I think that 100% code coverage is insane... The prob

I do test exceptions, I just don't test 100% of code paths. Do you encourage 100% code coverage? Because I think that 100% code coverage is insane... The problem is that as you approach 100% code coverage, the amount of effort it takes to test the remaining code paths skyrockets. At some point, you decide to stop writing tests. Then static typing steps in, and catches some bugs that were not cost effective to catch with testing. The exceptions are sometimes there because I am programming defensively... as in, "I don't think that it's possible for this condition to happen, but if it does, I'd rather raise an exception." Then I run mypy, and it tells me that there's no such thing as a VauleError. The other factor here is that when I exercise poorly tested code paths (which again, I'm going to assume exist), it's often because I'm in the middle of working on something else. The simple typo or bad call is an interruption.

deleted 5y ago
[deleted]
klyrs 5y ago
> Do you encourage 100% code coverage? Because I think that 100% code coverage is insane... [ed. note, wow you added a lot as I was typing out my response to this] Not as a hard and fast rule, but as a target to aim for. 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. I do a lot of my work in strongly typed languages; believe me when I say that code without type errors or variable misspellings can still be chockablock with bugs. In some codebases, 100% test coverage is equivalent to solving the Halting Problem. Don't sweat it.
- klodolph 5y ago
  > 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.

deleted 5y ago

[deleted]

klyrs 5y ago

> Do you encourage 100% code coverage? Because I think that 100% code coverage is insane... [ed. note, wow you added a lot as I was typing out my response to this] Not as a hard and fast rule, but as a target to aim for. 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. I do a lot of my work in strongly typed languages; believe me when I say that code without type errors or variable misspellings can still be chockablock with bugs. In some codebases, 100% test coverage is equivalent to solving the Halting Problem. Don't sweat it.

klodolph 5y ago
> 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.