I'm often asked by developers who are new to the platform what kinds of thing they should write unit tests for. In general, I find that question rather frustrating. Many factors go into answering that question, and without knowing the specifics of your org, it's impossible to answer comprehensively. On the other hand, it's much easier to answer the question what not to test? While the answer to that question isn't cut and dry either, it's at least simpler to provide guidelines for. With that in mind, here are some things you should most likely not test.
Managed packages have to provide their own unit tests. Additionally, you don't get to see the code from managed packages, so writing unit tests for managed package code is not only difficult, it's fruitlessly redundant as well. However, this isn't carte blanche for not testing your code that interacts with the managed package code. The only time I write unit tests for managed package code, is when I'm documenting a bug in that managed package!
I know this one seems obvious, but I've come across it numerous times. There's nothing to be gained from testing the basic constructs of the Apex language or built-in system-defined classes and functions. It is possible to test whether or not if() works, but what's the point? What you want to be testing isn't if() but the logical tests that go into that if() statement. Also in this category, we have declarative features, such as rollup summary fields, formulas, and validation rules. We write unit tests in part to prove functionality, but we need not write tests to prove platform functionality.
Aside from testing managed package code and standard platform features, the answer to what to test is everything, unless it doesn't make sense Testing, just like software development, requires judgment calls, and if something doesn't seem like it makes sense to test, it probably doesn't. However, you should always maintain the posture of testing everything and ruling out only what clearly doesn't make sense.