My second rule of testing

For a long time, I've told people that I recommend adding tests for any code that is "non-trivial".

I define non-trivial to mean any code that you can't look at and immediately see all the possible paths through it and potential outputs, such that you can see that all possible negative and edge-case consequences are correctly handled. Yes, the reality is that very little code meets this threshold.

I also make exceptions for plumbing code.

I now have a second rule. Well, guideline:

Include tests for anything that may be affected by a change in a dependency.

This matters because dependencies change and get updated. Without tests to verify that nothing has broken or been altered in unwanted ways, switching to using a new version of a dependency is a bigger risk than it should be or that you probably want to have to deal with.

Oh, that package you use now has a new version that reportedly fixes a security vulnerability. How quickly can you switch to using the new version? Do you trust that there are no other changes or consequences of updating? Can you be sure? Do you have the time to verify manually?

Also note that this applies to both internally and externally sourced dependencies.