Size: a a a

testing_in_python

2021 May 11

АГ

Андрей Грушевой... in testing_in_python
источник

BS

BLVCK SONNET in testing_in_python
MacOS, M1, Docker
После двух дней битья головой об все особенности поставил всё необходимое. Python ставил через brew, затем снёс и поставил с помощью инсталятора для макоси. Запускаю тесты в рабочем проекте:
- сборка контейнеров немного медленнее, но тут хрен с ним
- сессия pytest из 130 тестов проходящая на ubuntu за ~100 сек идёт уже минут 20... всё проходит, но очень медленно... если тесты в другом проекте будут завязаны на таймаутах - в текущей ситуации всё попадает

Если кто знает в чём может крыться данная проблема - хелпаните

PS: в тестах используются заглушки(aiohttp) поднятые локально, тестируемый сервис поднят локально, бд в докере(postgres)

Зависимости:
[tool.poetry.dependencies]
python = "^3.8.5"
asyncpg = "0.21.0"
uvloop = "0.15.2"
jsonschema = "3.2.0"
orjson = "3.5.2"
yarl = "1.6.3"
defusedxml = "0.7.1"
pytz = "*"
lxml = "4.6.3"
iprpc = "0.2.3"
postgres = "3.0.0"

[tool.poetry.dev-dependencies]
sphinx = "*"
sphinx-rtd-theme = "*"
flake8 = "*"
mypy = "*"
bandit = "*"
safety = "*"
pytest-cov = "*"
pytest = "*"
pytest-asyncio = “*”
источник

OC

Oleg Chaplashkin in testing_in_python
Опа, а вот и реальные кейсы от М1 подъехали.
Сложно что-то советовать, наверное нужно идти путем локализации дефекта.

Сначала, я бы исключил докер. То есть поднять тесты вне контейнера и БД также. Много проблем всплывало с М1 по докеру.
источник

ИС

Игорь Середа... in testing_in_python
А что значит "сборка контейнеров"?
источник
2021 May 12

EB

Evgenii B in testing_in_python
Думаю это значит что вместо пулла контейнеров ты билдишь их из контекста
источник

ИС

Игорь Середа... in testing_in_python
Но билдишь ты образ, а не контейнер. И это делается один раз.

Я думаю, тут в пору показывать не используемые пакеты, а compose-файл, как минимум.

Вообще, слегка похоже, что на каждый тест генерится новая схема, оттуда и время увеличивается. Но без кода это домыслы.
источник

BS

BLVCK SONNET in testing_in_python
Именно, я оговорился, docker build в одном из проектов работает крайне медленно. Там два Dockerfile’a, а сам тестируемый сервис поднимается в другом процессе
источник

ИС

Игорь Середа... in testing_in_python
Поинт моего вопроса вот в чём: условия тестирования на x64 и на m1 не отличаются? Это прям одинаковые пайплайны с одинаковыми докерфайлами и compose-файлами?

Или, всё же, это попытка имитировать в образах то, что в ubuntu стояло в хост-системе?

От этого зависит, в какую сторону стоит смотреть.
источник

BS

BLVCK SONNET in testing_in_python
Основная проблема решена, в интернетах есть рекомендация по установке 2го brew и созданию алиаса ibrew, который по сути тоже самое, но указывает на интеловскую архитектуру. Суть в том, что в данное время стоит ставить всё через него… Медленное прохождение тестов было связано с низкой производительностью postgresql. Удалил его, поставил через ibrew, обновил пути в .bash_profile - всё полетело
источник

BS

BLVCK SONNET in testing_in_python
Условия не отличаются, в компании всё деплоится на убунту, у меня личный мак на м1, на котором хотелось бы запускать тесты по завершению их написания или правки. Причина в скорости работы лично у меня =)
источник

СС

Сказочный Сникерс... in testing_in_python
А есть варик мне например проверить на про16 с i9?
источник

ИС

Игорь Середа... in testing_in_python
Я понял. Выходит, дело было в трансляции инструкций для pg из x86_64 в m1.
источник

А

Андрей in testing_in_python
Подскажите, с высоты своего опыта, какие курсы или ресурсы помогут разобраться в построении автотестов? В частности область настройки pytest, написании апиклиента для тестирования API и прочее
источник

А

Андрей in testing_in_python
*извините, если вопрос не там/не тот/что-то еще
источник

EB

Evgenii B in testing_in_python
почитай закреп. посмотри примеры кода с с pytest на гитхабе. отметь все необычные вещи, которые нашел в коде у людей, разберись почему оно так. возможно, это будет антипаттерн, возможно, правильный юзкейс.
источник

EB

Evgenii B in testing_in_python
найди общее зерно среди 10-15 примеров кода, почитай документацию по пайтесту
источник

EB

Evgenii B in testing_in_python
источник

EB

Evgenii B in testing_in_python
подчерпни основные идеи что делают люди, если оно решает твою проблему - используй
источник

OC

Oleg Chaplashkin in testing_in_python
Курсы и ресурсы по автоматизации, как мне кажется, недостаточно раскрывают все, что необходимо. Часто вижу "опа, был ручным тестером? давай-ка за 1 день автоматизатором станешь и +100к к ЗП"
Поэтому,
1. API клиент клиенту рознь, все пишутся под какие-то цели. В закрепе есть список врапперов для многих  сервисов; Наверное, лучший вариант: читать код, писать свой клиент
2. Не всегда автотесты это ЯП и прочее. Если это напрямую к работе относится и нужно "быстрее и быстрее", то я бы посмотрел в сторону  маленьких скриптов и инструментов, тот же постман - ок;
3. По структуре системы и построению у меня такой опыт: смотрел основную структуру того, как люди оформляют проектов автотестов, писал решение "в лоб", видел, что у меня копипасты 50%, декомпозировал и выносил в блоки. Так и получались, сначала маленькие хелперы, потом фикстуры, потому сущности в системе и прочее.
источник

А

Андрей in testing_in_python
Доходчиво, спасибо
источник