Вообще юнит тестирование - важная вещь при разработке больших и не очень систем. Его основная задача проверить работоспособность конкретного компонента подсовывая ему так называемые заглушки (стабы и моки), цель которых отсечь этот конкретный компонент от взаимодействия с другими т.е. создать ему искусственную среду. Тогда если ваш тест валится то можно с полной уверенностью сказать, что проблема именно в этом компоненте, а не в другом где в результате ошибки возникшей в этом другом компоненте тест завалится.
На примере - если вы пишите тест public метода какого то класса и во входящих параметрах которого есть другие объекты классов - так вот их обязательно заменяют на заглушки, иначе ошибки возникшие в этих параметрах при отработке вашего теста завалят этот тест, хотя сам тестируемый метод как бы и не причем.

Забыл сказать, что целью юнит тестирования обычно является проверка адекватной отработки какой то бизнес логики и как бы не имеет отношения к стресс тестированию и другим всяким тестированиям.

И еще юнит тесты очень трудно использовать в проекте, скажем так, очень динамичном, где все постоянно переделывается по сто раз на дню в угоду заказчику или по другим причинам, т.к. цель у тестов прямо противоположная - это "зацементировать" кучу написанного кода, которое вроде как не должно подвергаться серьезным изменениям - например ядро какой то учетной системы и т.д.

Все выше описанное - имхо.