4 ms·

I'll bite. Why not ditch the "% test coverage" metric then, since as you just elaborated, it's not a good metric. I would prefer my language wasn't designed ar

• closeparen 5y ago
  I don't think the coverage metric is necessarily wrong to highlight error return branches: they are program logic you typed, and might have mistyped. I certainly have mistyped them. Checked the wrong error value, or returned a different error from the one I checked. You get to skip tests for default exception handling behavior in e.g. Java because you know the language is going to do; there's no opportunity for human error. It is possible to have company policies against abstraction and cleverness when working in more expressive languages, and this would achieve almost the same intent as Go, it's just that actually using Go is more convenient. The language is corporate bureaucracy. The whole point is what's not there. What can't go off in a weird directions on a per-project basis. What junior engineers in a high-turnover environment can't screw up. It's not by accident that the native toolchain will give you a test coverage report with untested error return branches in red. Google is just happy to pay people for that drudgery, I guess.
  • lawl 5y ago
    > You get to skip tests for default exception handling behavior in e.g. Java because you know the language is going to do; there's no opportunity for human error. I fundamentally disagree with that. the only thing you know in java is that it throws an exception that's maybe caught somewhere. That's an untested branch aswell.
    • closeparen 5y ago
      You don't have to write a test for "if this underlying call throws an exception, that same exception is propagated up to me," which is about 80% of the test cases I write for Go. You do have to test cases where exceptions are supposed to be caught and handled/eaten, which I agree is meaningful and relevant in all languages.
      • throwaway894345 5y ago
        You “don’t have to write the test case” in the case of exceptions, but then you’re not getting the same coverage as with go. Just because a branch isn’t represented syntactically doesn’t mean it doesn’t exist. Note also that Rust’s ? operator isn’t going to be saving you from anything here since it just uses fewer characters to express the same branching logic, while languages with exceptions use none. In general your org’s policies for what to test seems like a recipe for a low-value, high-effort test suite. Reminds me of the unit tests for getters and setters in Java.
        • closeparen 5y ago
          You get to take the language for granted; you don't get to take your own code for granted. "String reverse" is an easy function to write and the same instructions end up in my binary either way. But if you write your own, you'd better test it. If you import one from the standard library, no need, the stdlib has already done that. Functionality being in the language does not just save you typing; it also saves you testing. That's my point. I agree, given that Go is what it is, it's a bad policy.
          • throwaway894345 5y ago
            You aren’t testing whether exceptions propagate correctly, you test that you catch or don’t catch them appropriately just like you test whether or not you return your error appropriately. That said, doing this for every function you write is probably not going to lead to a high value test suite.
            • closeparen 5y ago
              “Make sure it doesn’t catch the exception” is like “make sure it doesn’t do a tap dance” - there are quite a few things a function could do, we don’t generally ask unit testing to prove negatives.
              • throwaway894345 5y ago