Size: a a a

testing_in_python

2021 October 04

IS

Idi Suda in testing_in_python
Кстати можно просто делать assert resp.json()
источник

B

Bola in testing_in_python
😂 и как? Совсем все плохо?
источник

P

Pengo in testing_in_python
Нет. Работает, свои задачи выполняет. Местами есть велосипеды, но с роботом как таковым это не связано, а лишь с тем, что e2e-тесты пилит 1 человек помимо еще нескольких задач.

Документация хорошая, есть свои приколы всякие, но терпимо.
источник
2021 October 05

СС

Сказочный Сникерс... in testing_in_python
Приглашаем на бесплатный QA Meetup от Levi9, который состоится 26 октября! 🔥

Поговорим о:
🔸«Mиграция с protractor: какой инструмент является наиболее перспективным», ━ Хотемский Александр, SDET at Doxy.me
🔸«OOP design patterns in e2e tests», ━ Михаил Лепский, Test Automation Engineer (JS) at Levi9

Модератор: Собур Сергей, Test Lead / Principal QA Engineer at Levi9

Дата: 26 октября, 19:00
Формат: Онлайн
Доступ: Бесплатно
👉🏻Регистрация
источник
2021 October 08

Mike Кernserj in testing_in_python
```def test_something():
   l = randint(0,10)

   assert l == 5
```

l =7, assert fail
Rerun

Здравствуйте.  Можно ли в пайтесте для рерана передавать параметр чтобы в следующий раз авбиралась любое число кроме 7 (потому что с 7 тест падает)?
источник

P

Philip in testing_in_python
брутфорс-подбор значений? Лишь бы билд зелёным был…
источник

P

Pavel in testing_in_python
привет, кто-то может подсказать такую штуку
запускаются тесты в несколько потоков через xdist..
При отправке результатов в Testrail через плагин pytest-testrail, создается несколько отчетов на каждый поток...
Как можно это исправить? Какая обычно практика?
Так как тесты запускаются через Jenkins, попробывал через junit отчет через плагин в jenkinsci/testrail-plugin , но при отправке ругается на {"error":"Field :results cannot be empty (one result is required)"}
Сам Jenkins отчет показывает
источник

А

Алексей in testing_in_python
это не потоки, а процессы. Поэтому каждый из них создает свой отчет. Так что правильный вариант - через дженкинс отправлять агрегированный. Что до ошибки - она как бы гуглится. Проверьте содержимое резалтов, там что то лишнее
источник

Mike Кernserj in testing_in_python
узко мыслите.
источник

P

Philip in testing_in_python
Можно попробовать хранить все возможные значения где-то вне теста и вызывать random.choice(). Придётся передавать это фикстурой.
Также переопределить сами механимы pytest, чтобы при реране из этого множества убирать невалидное значение. Гуглить, читать доки и пробовать. Отсюда и вопрос: а стоит ли это того? Какую проблему Вы хотите решить изначально? “Убрать при реране неподходящее значение” — это не та проблема, о которой я спрашиваю.
источник

P

Pavel in testing_in_python
Спасибо, из гугла я понял,  что формат отчета не по junit схеме, но что там менять?
источник

Mike Кernserj in testing_in_python
> переопределить сами механимы pytest, чтобы при реране из этого множества убирать невалидное значение
ага, вот это.
в том что это необходимо, сомнений нет, взвесила все за и против. Пойду гуглить, читать доки и пробовать, спасибо.
Думала мб кто сталкивался с нестандартными ситуациями, чтобы время сэкономить. Если нагуглю - сюда скину решение.
Спасибо!
источник

Mike Кernserj in testing_in_python
Хотя может и есть сомнения.
там просто тест именно для определенного типа элементов из всего множества. Таких элементов большинство, но иногда тест напарывается на меньшинство и скипается. Есть рераны, но часто тест умудряется всегда попадать именно на то что нам не нужно. Как-то пометить эти элементы нет возможности. Проверка на то что элемент нам подходит или нет возможна только через несколько подгружений (соответственно если эту проверку поместить в логику выбора, то это значительно замедлит тесты)
Поэтому вариант передавать то что нам неподходит при реране кажется самым нормальным. Захардкодить нет возможности, все может меняться очень часто.
источник

P

Philip in testing_in_python
Чтобы вне теста было видно, какое значение было выбрано, надо его в фикстуре посчитать. А может и вообще каждое значение делать фикстурой, а в хуках убирать ненужные фикстуры.
источник

V

Vita in testing_in_python
а что насчет маркировки skipif?
источник

P

Philip in testing_in_python
Посмотреть на структуру этиъ множеств и с ними поработать звучит легче, чем лезть в дебри пайтеста ради костылей.
источник

Mike Кernserj in testing_in_python
да я скипаю тест. Но он слишком часто скипается, хотелось бы чтобы он всегда находил подходящий элемент и прогонял тест
источник

Mike Кernserj in testing_in_python
> Как-то пометить эти элементы нет возможности. Проверка на то что элемент нам подходит или нет возможна только через несколько подгружений

ну я же написала, вот.
источник

P

Philip in testing_in_python
Не, не проверять подходит ли, а выбирать только из подходящих. Разбить первоначальное множество на пожмножества.
источник

А

Алексей in testing_in_python
Надо смотреть. Больше похоже что там что то задваивается
источник