Тестирование, часть 1. Вопросы на собеседовании

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

1️⃣ Назовите свойства юнит-тестов?
Хорошие юнит-тесты соблюдают принцип FIRST:

🔸F – Fast
Выполняются быстро. Никто не хочет лишний раз запускать медленные тесты. Один юнит-тест — не дольше 0.5 сек.

🔸I – Isolated / Independent
Любой набор тестов можно запускать в любом порядке, тесты не зависят друг на друга. Каждый тест сфокусирован на одном действии и наборе параметров. Если тест упал, то сразу понятно, где и при каких условиях возникла ошибка.

🔸R – Repeatable
Результат теста не зависит от операционной системы, конфигурации компьютера, внешних ресурсов и наличия интернета. Результат теста повторяется при многократном вызове.
⭐️ Это свойство хромает, когда тесты используют случайные числа или проверяют работу нескольких потоков.

🔸S – Self-Validating
У теста два результата — прошёл или нет. Разработчик не должен проверять записи в логе или сравнивать текстовые файлы.

🔸T - Timely
Тесты пишутся вовремя, в рамках той же задачи, что и основной код.

⭐️ Юнит-тесты должны быть читаемыми. Тогда их легко поменять, если бизнес-логика изменится. Сложно разбираться в методах test1(), test2(), test3() и переменных a, b, c.
⭐️ По тестам можно оценить инженерную культуру компании. Обратите внимание на количество и качество юнит-тестов, кто и когда их пишет. Если тестов нет, или сеньор пишет код и создаёт подзадачу «написать тесты» для джуниора - это дно. Откладывать тесты из-за дедлайна — тоже так себе.
⭐️ Тесты можно не писать для PoC (proof of concept) — временный код для проверки гипотез, который не связан с продакшн кодом.

Тесты организуют по структуре 3A (Arrange-Act-Assert), также встречается название Given-When-Then.

// given

Инициализация переменных и моков.

// when

Вызов проверяемого метода.

// then

Проверка результата и состояния других объектов.

3 блока должны чётко следовать друг за другом, тогда тест легко читать. Если после блока проверок идёт действие и дополнительные проверки — значит тест слишком большой.

2️⃣ Что такое TDD?
Test Driven Development - процесс разработки, когда сначала пишется тест, а потом код. Подробно это выглядит так:
▫️Написать тест для кода, которого нет
▫️Запустить тесты, новый тест падает
▫️Написать код, чтобы тест проходил
▫️Запустить тесты, тесты проходят
▫️Рефакторинг нового кода
▫️Запустить тесты, тесты проходят

Плюсы TDD:
➕Код сразу покрыт тестами
➕У класса удобный интерфейс, который сразу используется в тестах
➕Структурированный код

После этого следует такой диалог:
- А Вы лично используете TDD?
- Нет.
- Почему? У него же столько плюсов.
- Большой минус - частое переключение контекста и фокус на деталях. Мне удобнее написать простое рабочее решение, и только потом добавить проверки, валидацию и обработку ошибок. После этого в соответствии с требованиями как следует оттестировать то, что получилось. Я сразу пишу код, который легко использовать и тестировать, поэтому TDD меня только замедляет.
- Согласен.