Довольно часто можно услышать, что код автотестов должен быть простым, как молоток.
Несмотря на то, что язык — это всего лишь инструмент, который помогает ускорить работу тестировщика, и вроде бы можно написать что-то из говна и палок «лишь бы работало», всё-таки лучше думать немного наперёд.

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

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

Пара рекомендаций. Мы с вами уже смотрели принципы SOLID, и их нужно применять при написании автотестов. Потому что код тестов — это такой же промышленный код, только для другой области, и он должен быть максимально качественным.

✅ 1. Не лепите всё в один класс.
Техническая часть для отправки запросов должна быть отдельно, API-клиенты — отдельно, классы-помощники делите по бизнес-доменам.
Это позволит меньше лезть в техническую реализацию, а разделение по доменам поможет легче ориентироваться в коде.

✅ 2. Предпочитайте композицию вместо наследования, если это возможно.
Внедряйте зависимости — так код будет гибче и проще менять реализацию внутри.

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

✅ 4. Держите в голове вопрос: «А что будет, если изменится бэкенд?»
Сможете ли вы без боли пересадить ваш фреймворк на новый движок?

✅ 5. Опишите правила поддержки фреймворка.
Что и где писать, где хранить — единые правила помогают держать код в чистоте.
Если подход один, то и автоматизировать конвертацию методов или функций потом проще.

✅ 6. ЕЩЕ РАЗ! Используйте внедрение зависимостей! НЕ ДЕЛАЙТЕ ИНСТАНСЫ нужных классов в коде без острой необходимости, это очень тяжело потом рефачить и тестировать. Используйте фикстуры, это сделает код более прозрачным и понятным.

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

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

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы