Привет! А вот и вторая часть поста про принципы юнит-тестирования. Если в первой мы обсудили влияние тестов на разрабатываемые продукты и познакомились с теорией юнит-тестирования, то в этой обсудим некоторые практические моменты. Внутри поста — структура юнит-тестов, стили юнит-тестов, принципы рефакторинга, полезные советы для того, чтобы ваши юнит-тесты были эффективными и читаемыми, а также некоторые антипаттерны при написании тестов.

Ну и, конечно же, список источников, где можно получить дополнительную полезную информацию. В общем, начнём.

Структура юнит-тестов

В нашей команде при написании юнит-тестов мы стараемся использовать подход AAA — Arrange, Act, Assert (Подготовка, Действие, Проверка).

Кратко расскажу о нем. Тест делится на три блока, которые идут друг за другом. Ширина блоков на рисунке выше образно отражает объём кода, который должен занимать каждый из блоков.

Привет! Меня зовут Владимир, я разработчик команды продукта «Сервис персонализации» в SM Lab. В этом посте я хотел бы рассказать (а в комментариях — обсудить) один очень важный и полезный инструмент разработчика — юнит-тесты.

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

Мой рассказ будет состоять из двух частей. В этой части я расскажу, что такое юнит-тестирование и для чего это нужно, что такое покрытие тестами, как оно считается и какие есть подводные камни, рассмотрю подходы к изоляции в юнит-тестах и виды зависимостей, а также вопросы, связанные с эффективностью юнит-тестов.

Эта статья для всех – кто слышал про них, но не видел, кто приступает к написанию юнит-тестов, и кто их пишет уже давно. Надеюсь, каждый из вас найдет что-то полезное для себя.

При подготовке материала очень помогла книга Владимира Хорикова (@vkhorikov ) «Принципы юнит-тестирования». Рекомендую ее всем, кто хочет еще глубже погрузиться в эту тему.

Итак, поехали.