Как и многие разработчики, в начале своего обучения я забивал на написание тестов. Сейчас я расскажу, когда нужны тесты, и что именно вам нужно тестировать как разработчикам.
Сначала обсудим, когда можно НЕ писать тесты:
- Если вы разрабатываете MVP версию продукта, и нужно как можно быстрее выкатить приложение для пользователей, так что на тесты не остается времени
- Если вы разрабатываете прототип какой-то фичи, не понимая, войдет ли она в финальный продукт
Когда я только начинал делать Солвит и нанял команду разработчиков, разработка шла стремительными темпами. Каждый день добавлялись новые фичи и таблицы в базе. Причем код таких фичей затем часто дописывался либо полностью менялась логика как на бэке, так и на фронте. На этапе бурного роста проекта тестирование бесполезно.
Со временем код разрастался и появлялась реально сложная бизнес-логика. Например, логика по формированию собеседования в тренажере занимает 1000+ строк и завязана на десятке таблиц в базе данных, сложных SQL запросах и логике отбора вопросов для собеседования. Например, нужно было сделать так, чтобы в каждом собеседовании пользователю редко попадались вопросы, которые он уже проходил и отметил легкими, а сложные могут попадаться до тех пор, пока не станут легкими. Короче, все очень сложно)
Тренажер — одна из ключевых продуктовых фич проекта, и ее обязательно нужно покрывать тестами, потому что делать это руками — тяжело и неэффективно, в тренажере больше 50 комбинаций языков, фреймворков и грейдов.
Сейчас бэкенд Солвита разросся до 30к+ строк кода, и вот тесты, которые я считаю обязательными включать в любой средний и большой проект:
Для тестирования сейчас повсеместно используется pytest. Для моков, конечно, применяется unittest. На моем Практическом курсе по Backend разработке тестированию посвящен целый модуль.
Напиши в комментах, пишете ли вы тесты в компании 👇