3 ms·

Your just moving the problem one layer up. You still need to write a test for how it all comes together and you should write tests for your error handling. You

• bccdee 1y ago
  Not necessarily. If your error handling looks like this: value, err := externalLibraryFunctionFoo(a, b) if err != nil { return nil, fmt.Errorf("calling foo: %w", err) } then you probably don't need to test it. All you're doing is bubbling up the error handling from other libraries' functions.
  • tayo42 1y ago
    Tests help make sure that the intent is to just bubble up the error. What if someone in the future is comes in and modifies that to add some complexity somehow or changes it to log and continue. Tests will catch that behavior
    • bccdee 11mo ago
      It's rarely possible to future-proof a function by testing its entire range of possible inputs, so I'm not particularly concerned about trying to anticipate trivial cases that might become non-trivial in future—that just feels like a special case of future-proofing. I think it's more important to ensure that, after each new commit, every non-trivial code path in that function is exercised. If someone adds new logic, they're responsible for adding new tests to cover that logic; similarly, if they turn a trivial code path into a non-trivial one, they're responsible for adding tests to cover that too.