Как писать юнит тесты

как писать юнит тесты

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

В этой статье, я постарался описать процесс создания юнит тестов исходя из собственного опыта.

Первое, что нужно помнить — мы пишем юнит тесты. Это значит, что нужно тестировать определенную программную единицу. Как правило, для одного метода, пишут минимум один тест кейс. Под тест кейсом я имею ввиду тестовый метод, а не класс.

И так. Вам нужно протестировать определенный сервис. Начните с создания класса который будет хранить методы по тестированию. Как правило, подобные классы размещают в папку tests. Я пользуюсь инструментом intellij idea. Находясь в классе, который нужно протестировать, я просто жму Ctrl+Shift+T комбинацию, и приложение перенаправляет меня в тестовый класс. Или такового еще нет — предлагает создать.

Потом, нужно взять отдельный метод, который Вы собираетесь протестить и тщательно его проанализировать. Нужно понять следующее:

  • какие входные данные ему нужны;
  • какие сторонние классы использует метод в своих вычислениях;
  • что он должен вернуть в случае успешной работы;
  • что он вернет когда например сторонний метод вернет не тот результат, который он ожидает;
  • что будет возвращено если входные данные будут не те которые он ожидает.

Все эти моменты нужно просмотреть и проанализировать. Особенно не просто тестировать метод, который выполняет несколько действий. Именно поэтому нужно следовать SOLID принципу (Single responsibility). Так и код будет выглядеть приятней, и тестировать его будет легче.

Дальше, нужно подготовить входные данные, которые нужны методу. Потом замокать поведение сторонних методов, которые он использует в своей работе.

Когда все это готово, можно вызывать тестируемый метод и смотреть на результаты его работы. Тот результат, который мы ожидаем получить, нужно сравнить с тем что есть.

Теперь более подробно.

Подготовить входные данные. Это достаточно просто. Смотрим, какие объекты или параметры принимает тестируемый метод и создаем их. Если это большой объект — лучше создавать тестовые данные в отдельном классе. Чтобы не захламлять тестовые файлы.

Замокать поведение методов и классов, которые использует тестируемый метод.

Редко когда бывает такое, что метод выполняет определенный код не вызывая других сервисов из сторонних классов. Особенно, если мы говорим о коде на реальных проектах. Поэтому очень важно замокать поведение сторонних методов, чтобы иметь возможность протестировать только работу одного участка кода, на который мы нацелились. Недаром это юнит тест.

Придумывать велосипед не нужно. Есть масса библиотек, которые позволяют запрограммировать имитацию работы методов и даже классов. Одна из таких (не единственная) библиотек — Mockito. Проста в использовании и настройке. Все что вам нужно — подключить мокито зависимости к проекту и просмотреть пару видеоуроков как мокать поведение с помощью этой библиотеки. В конце статьи я дам ссылку на видеоурок где мы используем mockito.

Для того, чтобы сравнить результат выполнения метода с ожидаемым — есть масса библиотек, которые очень просты в использовании. Первое что приходит на ум всем программистам Java — библиотека Junit. Подробнее о ней есть отдельная статья. Уточню только, что это достаточно мощный и гибкий инструмент для написанию юнит тестов. Особенно последние версии Junit, которые позволяют протестировать буквально все сценарии с минимальным количеством кода.

Не нужно писать тесты ради тестов. Тест должен покрыть определенный сценарий, который по мнению программиста может произойти на самом деле.

Например авторизация пользователя. Если я возьмусь за написание тестов для метода который это делает, я в первую очередь пишу тест который проходит удачный сценарий. Передаю логин, пароль. Смотрю чтобы база данных возвращала мне юзера на мои логин и пароль.

Дальше, я как минимум напишу один тест, который покрывает неудачный сценарий. Я передам в метод данные без логина. Потом я посмотрю — выбрасывает ли мой метод ту ошибку, которую я ему запрограммировал на пустой логин. Потом можно написать еще один тест кейс для проверки сценария, когда база данных не нашла пользователя по логину и т.д.

Написание юнит тестов это работа которая не видна заказчику. Они не наполняют Ваше приложение функционалом. Возможно, именно поэтому очень часто программисты игнорируют эту стадию процесса при разработке приложений. НО! В долгосрочной перспективе — тесты (не только юнит) ускоряют разработку и полностью окупают себя финансово. Когда тестом можно отловить баг, который бы стоил фирме потери денег или репутации — тогда написание тестов по настоящему себя оправдывает.

Поэтому, не игнорируйте тесты в своих приложениях (особенно юнит). Так как это очень важная и ценная часть разработки приложения.

Я записал небольшое видео где на примере показал, как можно покрыть тестами практически все слои веб приложения.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *