4 ms·

At very least, unless you hate other developers for some reason, you need to document in your test suite what errors are returned. How, exactly, are going to f

At very least, unless you hate other developers for some reason, you need to document in your test suite what errors are returned. How, exactly, are going to forget a necessary `if err != nil` without your test suite blowing up? If you do hate other developers for some reason, why not leave out some `err != nil`s to really drive home your hatred towards them?

kelnos 3y ago
If you can forget to check an error at a call site, then you can just as easily forget to add a proper test for that error condition. I prefer writing in languages where the syntax and standard library and compiler will help me avoid mistakes, and not have to rely on tests -- more error-prone code I have to write! -- to do that for me (and yes, I understand that I will never avoid having to write some tests, but the more the language and compiler can do for me, the better). A language with generics and sum types (so you can implement something like Either, Try, or Result) doesn't let you use the result of a fallible function call without handling the error explicitly. And if the result is unit/void, most compilers/linters will still warn you if you haven't used the Either/Try/Result type that's returned. But ultimately it doesn't matter. Write in whatever language you feel comfortable and most productive. Well, unless you're starting a new security-sensitive project and want to write in C. Just... stop.
- randomdata 3y ago
  I don't follow. Errors are part of your functional specification. Not even a complete type system can avoid you needing to write tests to document the error conditions. We are not talking about writing tests to stand in where an incomplete type system may be lacking. Assuming you don't hate other developers, and given the tests you would write in any language, how do you foresee missing an error branch? Again, not specifically trying to test for something that a sufficiently advanced type system would catch, just your regular level documenting that demonstrates to other developers that you don't hate them. > then you can just as easily forget to add a proper test for that error condition If an error condition is easily forgotten in the documentation, then who cares about the implementation thereof? It is obviously not important. In fact, it is arguable that your program is incorrect if you do handle the condition in such a case.
bananapub 3y ago
what tool do you use to verify that every possible path your program, including all errors paths in dependencies, is executed?
- randomdata 3y ago
  If you are referring to test coverage, the standard Go toolchain includes that out of the box. But in this case you don't need to know about what paths have been executed. It will be obvious that an error path was not handled when your program does not adhere to function that is documented.
  - tripleo1 3y ago
    > including all errors paths in dependencies

kelnos 3y ago

If you can forget to check an error at a call site, then you can just as easily forget to add a proper test for that error condition. I prefer writing in languages where the syntax and standard library and compiler will help me avoid mistakes, and not have to rely on tests -- more error-prone code I have to write! -- to do that for me (and yes, I understand that I will never avoid having to write some tests, but the more the language and compiler can do for me, the better). A language with generics and sum types (so you can implement something like Either, Try, or Result) doesn't let you use the result of a fallible function call without handling the error explicitly. And if the result is unit/void, most compilers/linters will still warn you if you haven't used the Either/Try/Result type that's returned. But ultimately it doesn't matter. Write in whatever language you feel comfortable and most productive. Well, unless you're starting a new security-sensitive project and want to write in C. Just... stop.

randomdata 3y ago
I don't follow. Errors are part of your functional specification. Not even a complete type system can avoid you needing to write tests to document the error conditions. We are not talking about writing tests to stand in where an incomplete type system may be lacking. Assuming you don't hate other developers, and given the tests you would write in any language, how do you foresee missing an error branch? Again, not specifically trying to test for something that a sufficiently advanced type system would catch, just your regular level documenting that demonstrates to other developers that you don't hate them. > then you can just as easily forget to add a proper test for that error condition If an error condition is easily forgotten in the documentation, then who cares about the implementation thereof? It is obviously not important. In fact, it is arguable that your program is incorrect if you do handle the condition in such a case.

bananapub 3y ago

what tool do you use to verify that every possible path your program, including all errors paths in dependencies, is executed?

randomdata 3y ago
If you are referring to test coverage, the standard Go toolchain includes that out of the box. But in this case you don't need to know about what paths have been executed. It will be obvious that an error path was not handled when your program does not adhere to function that is documented.
- tripleo1 3y ago
  > including all errors paths in dependencies