Я бы посоветовал начать с того, чтобы писать тесты для того, что уже упало. Например, после тестирования тестер сказал, что при нажатии кнопки «Создать документ» падает исключение. Ок. Пишете тест, который это воспроизводит. И только потом чините исключение.
Примите за правило прежде чем сломя голову бросаться чинить такие ошибки — сначала написать тест. Со временем придет понимание и что тестировать, и как, а главное — после тяжелых мучений в духе «Блиииин. Ну вот и как написать тест для ЭТОГО?» придет понимание как писать код так, чтобы его можно было тестировать.
Здесь уже написали кучу примеров как писать тесты для разных ситуаций — «вот если есть то и это, то тест надо писать так». Но самый лучший генератор примеров — жизнь. Пишите тесты. Учитесь на своих ошибках. Ну, как обычно.
Еще люто рекомендую системы автоматической сборки и тестирования, описанные в посте Wott'а. Например, у нас после push'а в СКВ — на специально выделенном сервере происходит сборка проекта и запуск всех тестов. Главное преимущество в этом лично для меня — практически нет необходимости гонять тесты на моей машине. Ведь наши тесты могут работать по несколько часов.
Также могу посоветовать различные программы для анализа покрытия тестами. Часто такие программы помимо непосредственно анализа покрытия умеют анализировать и некоторые другие полезные метрики. Например,
С.R.A.P. — метрика. Сортировка по такой метрике может помочь обнаруживать сложные, не покрытые тестами функции. Для них стоит писать юнит-тесты в первую очередь.