In writing unit tests, you should always use your own judgement on what and how much to test. No textbook rule can fit every specific project and situation. We have limited resources, which we should use sparingly to get the most benefit for the given time and effort. Ther are always code parts which can't be reasonably unit tested, but there may be better ways to test them such as integration / system / functional tests.

Even on the classes you do unit test, it is hardly reasonable to expect 100% coverage. There is always error/exception handling code etc. which is hard to test and doing so doesn't bring much benefit (if at all).

So for every class / method you should ask yourself (or rather your team if you are unsure) whether you are confident enough that this code won't break. If not, work out a way to test it, be it unit or other kinds of tests.

In writing unit tests, you should always use your own judgement on what and how much to test. No textbook rule can fit every specific project and situation. We have limited resources, which we should use sparingly to get the most benefit for the given time and effort. Ther are always code parts which can't be reasonably unit tested, but there may be better ways to test them, such as integration / system / functional tests.

Even on the classes you do unit test, it is hardly reasonable to expect 100% coverage. There is always error/exception handling code etc. which is hard to test and doing so doesn't bring much benefit (if at all).

So for every class / method you (or prefereably the whole dev team) should ask yourself whether you are confident enough that this code works. In other words, can it be shipped today? If not, work out a way to ensure its quality, be it unit or other kinds of tests.