It seems to be generally assumed (on Stack Overflow at least) that there should always be unit tests, and they should be kept up to date. But I suspect the programmers making these assertions work on different kinds of projects from me - they work on high quality, long-lasting, shipped software where bugs are A Really Bad Thing.

If that's the end of the spectrum where unit testing is most valuable, then what's the other end? Where are unit tests least valuable? In what situations would you not bother? Where would the effort of maintaining tests not be worth the cost?

I will personally not write unit tests for situations where:


The code has no branches is trivial. A getter that returns 0 doesn't need to be tested, and changes will be covered by tests for its consumers.
The code simply passes through into a stable API. I'll assume that the standard library works properly.
The code needs to interact with other deployed systems; then an integration test is called for.
If the test of success/fail is something that is so difficult to quantify as to not be reliably measurable, such as steganography being unnoticeable to humans.
If the test itself is an order of magnitude more difficult to write than the code.
If the code is throw-away or placeholder code. If there's any doubt, test.

