Я не уверен, что могу согласиться с любым исключениями, которые вы упомянули в своем ответе.
Методы без логики
Даже если метод просто делегирует свою реализацию внутренней зависимости, очень важно убедиться, что это происходит. Я предполагаю, что вы пишете код по какой-то причине, поэтому вам нужно написать тест, который гарантирует, что он останется таким.
Помните, что одним из ключевых преимуществ модульных тестов являются наборы регрессионных тестов. Проверка правильности вызова внутренней зависимости называется тестированием взаимодействия. Скажем, у вас есть следующий метод:
public void Save(Entity entity)
{
this.repository.Save(entity);
}
Очень важно проверить, что метод Save хранилища вызывается с правильным вводом. В противном случае другой разработчик может прийти позже и удалить эту строку кода, и набор регрессионных тестов не будет предупреждать вас.
Помните: простые вещи не гарантируют, что они останутся простыми.
Не тестирует операции с базой данных
Считаете ли вы несущественным, правильно ли хранятся данные в базе данных? Если вам действительно, по-настоящему, все равно, то вам не нужно проверять это - иначе вы делаете.
Если вы не тестируете работу своей базы данных, как вы узнаете, что ваш компонент доступа к данным работает?
Я не говорю, что вы должны проверить свою библиотеку ORM, но вы должны проверить, правильно ли она используется.
Не тестирование объекта во всех слоях
Я не уверен, что вы имеете в виду под этим вопросом, но если поле может быть нулевым, и это проблема, вам нужно проверить, что происходит, когда оно фактически нулевое - везде.
Гораздо предпочтительнее спроектировать API так, чтобы значения гарантированно не были нулевыми.
Заключение
Вы должны проверить все, что вы можете проверить. Без исключений. Простые вещи не остаются простыми, и вы должны быть в состоянии убедиться, что код, который когда-то работал, продолжает работать.
Существуют вещи (например, пользовательский интерфейс), которые вы не можете модульное тестировать, и их следует абстрагировать, чтобы они содержали как можно меньше логики, но все остальное следует проверять.
Разработка через тестирование (TDD) - лучший способ обеспечить это.