Comment by tayo42

3 months ago

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 need a mock to respond with an error.

3 comments

tayo42

bccdee 3 months 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 3 months 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 3 months 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.