Автотестирование: десять лайфхаков от команды Skyeng

[nizkopal]

Спасибо за статью. :)

Делитесь своими лайфхаками и мыслями в комментах!

Как один из, мы написали скрипт, который проверяет, что возле всех TODO в коде тестов есть обязательно номер тикет, связанного с этим TODO. Например:

// remove after JS-123
// add more cases after JS-134

Таким образом мы не подвергаемся соблазну создавать TODO без тикета. Ведь если нет тикета, как известно, нет и задачи, а TODO будет висеть вечно.

Есть еще второй скрипт. Он по крону парсит код с TODO, собирает все тикеты и по JIRA API проверяет их статус. Если тикет уже закрыт, скрипт пишет в рабочий чат ответственному примерно такой комментарий: «JS-123 closed. Remove TODO in FileName line N».

Это позволяет не забывать сразу по закрытию тикета, ради которого TODO создавался, приводить код в порядок.

[aviskase]

скрипт, который проверяет, что возле всех TODO в коде тестов есть обязательно номер тикет, связанного с этим TODO

О, хорошая идея, надо тоже такое сделать. Мы используем pylint, поэтому можно написать проверку в виде плагина.

К слову о лайфхаков, использование линтеров (pylint и mypy) резко повысил качество кода автотестов: старые тесты писались абы как на 2ом питоне, и у автописунов до сих пор проклевываются плохие старые привычки.

[AndrewQA777]

Согласен, линтеры стоит использовать. У нас есть некоторые различия в настройках для линтера внутри директории с автотестами (они хранятся в монорепе с продуктом), но все автотестеры в команде используют

[AndrewQA777]

Спасибо за идею! Да, сейчас есть проблема с поддержанием актуальности TODO

[ph1l1n1]

Частый запуск на проде – каждый час – помогает отлавливать инфраструктурные проблемы (недоступен внешний сервис, лег наш сервер)

Т.е. вы используете какой то набор UI и не только тестов для мониторинга работоспособности боевого сервера? разве не существуют специальные системы логирования происходящего на боевом сервере?

[AndrewQA777]

Есть специфические ситуации, в которых системы мониторинга не видят проблему. Например, из недавнего — CDN-сервис отдавал не ту версию контента, никаких ошибок в системах мониторинга при этом нет (вроде какая-то проблема с кешированием была). Однако поведение начинает отличаться от ожидаемого. Автотесты это засекают — системы мониторинга нет)

[Gennadii_M]

Мне одному кажется, что это не совсем лайфхаки, а скорее подходы и практики? При чём многие из них достаточно очевидны. Например «фиксируйте баги» — а как иначе то? Шаблонным строкам уже 5-ый год от роду и это довно считается best practice, но никак не лайфхаком. Стрелочные функции туда же. Только я бы добавил, что не всегда нужно «избегать проблем с указателем this из JavaScript». Сделайте так с итом в моке и поменяте this.retries(2).

[spasibo_kep]

Геннадий, здравствуйте.

> Мне одному кажется, что

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

[Gennadii_M]

Лайхак — это что-то необычное. Нестандартное применение стандартным вещам. Например, сделать начадку-вентилятор на дрель и раздувать этим делом угли или прокчировать пейджи с элементами, чтобы получить автоматическое логгирование. И, видя заголовок про лайфхаки, я ожидал увидеть именно это, а не «дуйте на угли, чтобы их раздуть» или «используйте typescript, бо у него автокомплит есть».
Я не говорю, что статья не имеет права на жизнь, но контент не соответствует названию (имхо, конечно же).