I should have explained what I mean by trivial: I think any competent programmer knows the value of testing. So in that sense saying that you should write tests is like saying you should write good code - it is true, but not very insightful.
In a time constraint environment, you often need to make a choice between more tests and more features, etc... I have seen a lot of people who said their code was great because it was well tested, but then the tests depend so much on the implementation that it actually goes against better code (since refactoring may mean breaking a lot of unit tests). So the more interesting question is: what to test, how, and how far. For example, my own rule for testing is that in general, I don't test something if testing it takes more code than the feature itself (except for regression testing, and things which really play well with testing, like parsers and the likes, and code which needs to run on many different platforms).
It is also useful to recognize when testing has value, and to avoid overestimating its actual benefits. Too often, people don't really think about failures when testing, or how the API it exercices can be used in a straightforward manner or not. For example, I don't get so much the value of TDD - I find it much more useful to think in terms of API usecases, for which small tests are often not well suited. Sure, designing for easy testing can help, but you can get the same benefit without TDD in my opinion.
Finally, too often, I see "this library is well tested" sold as a feature in open source projects - but test coverage is not a feature. Sure, everything else being equal, I would prefer a well tested library to a not well tested library. But everything else is not equal: there is a constant tradeoff between designing better API, getting a better documentation or installation process and testing.