[yoran]

In my current work, which a GraphQL backend API, I've identified only two use cases for unit tests:

- complex pure functions. For instance, I have a street address "cleaner". The input is an unclean street address (weird capitalisation and so forth) and ouputs a clean address. Unit tests are perfect here because they're fast, and it's an isolated piece of logic that has no side-effects (no writing to DB or network request).

- wrappers around third-party libraries. Yes, in theory you're supposed to trust that a library will respect its API unless major version changes etc. In practice, it's not the case. And I'm also lazy and don't want to read all the release notes of all the libraries when doing updates. By wrapping a utility function from a third-party library and unit testing that function, I can have real confidence that the library still works in the way I'm expecting it to work. And it fails loudly when it no longer does.

Outside of these, I only have end-to-end tests that test the whole stack: send a GraphQL query and check that the resulting JSON is what I expect.

[ramses0]

> - wrappers around third-party libraries.

That's an "acceptance test" or "fit for purpose" test in case you're looking for industry terms.

Closely related is "law of demeter" (the law of one dot), as it buffers you from changes in dependent API's.