Идальго Диас Николай
@NikolayHD
Разработчик инфраструктуры автотестов
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Works in
- Date of birth
- Registered
- Activity
Разработчик инфраструктуры автотестов
Information
противофактическое измерение, http://quantmag.ppole.ru/forum/index.php?topic=453.0
согласен
Оказывается, есть доклад про релизный цикл, там уже написано про интеграционные тесты Яндекс.Такси.
они не делают, это был просто кривой копипаст, в действительности бывает такое
В данном случае по шкале Максимальная элегантность <----> Минимальное время, затраченное на форматирование сделано предпочтение в пользу скорости. Когда я добавляю новый код, мне это не нравится, но когда приходится вносить большие правки в чужой код, править кофликты слияний и т.п. то наоборот, нравится.
Когда над кодовой базой работают сотни людей, возможность отформатировать правки автоматически является решающей для того, чтобы разрешать конфликты с новыми правками быстрее, чем появляются новые.
Без async / await не обойтись в коде тестов. Если под везде подразумевается что-то ещё кроме кода тестов, то нет, не везде. В частности, сервис не обязан использовать async, а может вообще быть написан на другом языке, скажем C++.
Я готов согласиться, что где-то магические строки / числа по коду не нужны, но, ещё раз, это верно не всегда. Часто бывает так, пишешь вначале тест с константами, получается лаконично, но сходу не понятно, что проверяется. Заменяешь константы на значения, и стало понятнее.
Конечно нет, разработчик должен выписать ожидаемый в ответе json отдельно, но речь о другом. Мы не навязываем конкретный способ, которым это будет сделано. Можно просто сравнить dict в питоне, можно прикрутить фреймворк на ваш вкус.
Мы форматируем код по pep8, с длиной строки в 79 символов.
В данном случае мы форматируем строку для записи в лог, а если не смогли раскодировать, то логируем ошибку, из которой будет видно, в чем дело.
0 означает, что операционная система выберет любой порт. Это стандартное значение для bind(2).
Проект действительно enterprise, появился и развивается решая конкретные задачи. Это верно сейчас, это будет верно и в будущем, когда проект будет и декомпозирован, и почищен, и так далее, будем заниматься этим, обязательно.
Асинхронные обработчики нужны, например, чтобы моксервер отвечал на запросы, пока тест ожидает ответ сервиса, без асихнронности никак.
Бывает, особенно часто в предусловиях и проверках, что код оказывается проще и понятнее, если не выделять константу.
Согласен, но это необходимо написать только один раз. Обычно мы используем кодогенерацию и пути подставляются на этапе cmake.
Действительно, значительная часть кода ещё не покрыта аннотациями, это наследие тех времён, когда проект работал на python2.7/gevent. Мы постепенно добавляем аннотации в имеющийся код и используем их в новом.
pytest патчит assert-ы таким образом, что к ним можно подключить свои собственные обработчики, получается довольно удобно.
Сервис chat-backend не взаимодействует с базой, за это отвечает другой сервис, chat-storage-postgres, вот когда мы тестируем chat-storage-postgres, тогда и наливаем базу.
Действительно, testuite может поднимать базу самостоятельно и «запускать в этом окружении тестируемый сервис», а может воспользоваться и готовым окружением, в том числе поднятым в docker, что удобно в CI. Мы в Яндекс.Такси используем оба решения.
Это введение, мы стремимся дать примерное представление, более целостное картину дают последующие разделы статьи.
Потому что они прендазначены для решения другого типа задач. Статья про testsuite, а не юнит тесты, поэтому здесь мы не будем углубляться.
Тут есть несколько вариантов, как это обойти: можно передавать пути через аргументы, через переменные окружения или вычислять их на ходу. В данном случае мы добивались того, чтоб тесты запусальись без указания дополнительных параметров. PYTHON3 необходима для того, чтобы можно было запускать тесты в окружении отличном от окружения самого testsuite.
А в общем: согласен, что не очень красиво — поправим.
В самом деле, list :)
Спасибо, исправили.
С помощью make-файла мы показываем, как можно запустить нужные команды, мы не настаиваем на использование make.
Мы стремимся, насколько возможно, не навязывать пользователю выбор инструментов, поэтому testsuite предоставляет базовую функциональность. Поддержку валидации, скажем через marshmallow, можно добавить в своем проекте. Например, в Яндекс.Такси все ручки описаны с помощью yaml-схем, поэтому дополнительная валидация нам в этом месте не очень полезна.