Олег

Как и сказал Сергей Горностаев , пользу от Unit-тестов можно увидеть только в серьёзном и большом проекте, а так же при автоматических сборках проекта. Задача Unit-тестов проверить, правильно ли выполняется логика тестируемого метода и возвращает ли он ожидаемый результат. Желательно, не выходить за пределы тестируемого класса, то есть, если класс использует какие-то внешние ресурсы или другие классы, то стоит съэмулировать (замокать) эти ресурсы и классы, так как они должны быть протестированы отдельными тестами. Таким образом мы тестируем только код конкретного класса, предварительно зная, что будут возвращать нам другие классы.

Допустим, у нас есть какой-то маппер книги из сущности БД в объект DTO. В этот маппер инжектится репозиторий книг, из которого по id можно получить книгу.

public class BookMapper {
    @Inject
    private BookRepository bookRepository;

    public BookDTO mapToDTO(Integer id){
        Book book = bookRepository.findOne(id);
        return new BookDTO(book.getId(), book.getName());
    }
}

Наша задача протестировать логику этого маппера. Мы можем замокать репозиторий, так как сейчас тестируем не его (на него должны быть отдельные тесты), и проверить, вернёт ли нам маппер нужное DTO, если ему передать какой-то id. Настраиваем мок репозитория и вызываем нужный метод. После чего сравниваем ожидаемый результат, с полученным результатом:

@RunWith(MockitoJUnitRunner.class)
public class BookMapperTest {
    @Mock
    private BookRepository bookRepository;

    @InjectMocks
    private BookMapper bookMapper;

    @Test
    public void testMapToDTO() {
        // Мокаем репозиторий. Он возвращает конкретную книгу при передаче ему
        // конкретный id
        Book book = new Book(20, "Конституция");
        Mockito.when(bookRepository.findOne(20)).thenReturn(book);

        // Ожидаемая книга
        BookDTO expectedBook = new BookDTO(20, "Конституция");

        // Полученная из маппера книга
        BookDTO actualBook = bookMapper.mapToDTO(20);

        // Сравниваем ожидаемую книгу и полученную книгу
        Assert.assertEquals(expectedBook, actualBook);
    }
}

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

В данном случае пример совсем простой. На реальном коде нужно тестировать все уникальные сценарии работы метода. Например, если в методе есть ветвление if, перебор switch, бросание исключения и т.д., то необходимо протестировать каждый вариант.