Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: