2.7.3

Или вот так))

самое простое посмотреть депенденси)

ох, попробую, спасибо

Да, видимо все-таки такой вариант не очень. То ли проблема с ОС, а может и вообще в 3 питоне OSError: [WinError 6] The handle is invalid

наверное в те далекие времена все-таки юзали 2-ой питон больше)

Судя по всему да) Тогда может есть смысл вернуться к nose, но там какая-то странная вещь происходит, после прогона тестов и отображения результатов, процесс продолжает висеть минут 5, при этом почти на 100% нагружая оперативку. Это не связано с allure, с ним и без него такое происходит. Гуглил вчера очень много на этот счет, у кого-то такое было, но решений не было. Может кто-нибудь сталкивался? Или как-то это можно подебажить?

Всякие verbose и прочее это не отображают

Товарищи, есть вопрос и возможно он холиварный, но интересно ваше мнение. Все мы проверяем логику приложения в апи тестах, геты, сеты, возможно в базу кто-то лезет с проверкой после запроса апи. Как определить ту грань, при которой реализация проверки бизнес логики превращается в повторение кода приложения, но уже в самом тесте? И правильно ли это?

Тоже таким вопросом задавался. В зависимости от текущего времени и локации нужно было рассчитать ближайшее доступное время доставки. Была куча параметров, исключений и т.д. сижу и думаю, что пилю код, который должен быть таким же как у разрабов.
Всё-таки пришел к выводу, что надо определить набор входных параметров (тест дизайн там всякий :)), один раз рассчитать ожидаемые результаты и в приложении эмулировать время и место для теста, а не брать текущее рандомное и не производить расчет на лету.

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

Кстати если есть ответ на этот вопрос в книгах/статьях - скиньте плиз, очень интересно. Ибо часто бывает так, что разрабы открещиваются от юнит тестов, мол такую сложную бизнес логику не проверить в юнитах, ее надо пилить именно в апи тестах. Но по сути своей эти проверки сложности логики могут быть реализованы в юнит тестах более раздроблено так, что и апи тесты писать не придется. Может я и не прав, конечно.

коллеги, если у меня от клиентского ява-кода до chromedriver.exe соединение через прокси, я должен RemoteWebDriver создавать через HttpCommandExecutor ? от chromedriver.exe в сторону тестируемых ресурсов прокси при этом нет

сам хром пусть работает без прокси, ещё раз уточняю

в этой ситуации соглашусь с вашими разработчиками, у меня  такое же видение(по крайней мере, это справедливо для текущего проекта). возможно, если они не хотят писать юнит, их можно привлечь к интеграционным?)

> Но по сути своей эти проверки сложности логики могут быть реализованы в юнит тестах более раздроблено так

Для этого нужно делать декомпозицию кода, чтобы сделать его тестопригодным, а это ох как не хочется 🙂

Он холиварный, конечно, но (и) с другой стороны.

Я уже рассказывал, может, про вариант моих задач -- логика даже не повторена мною, она скопирована. Те же юниты работают.

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

Меня это вполне устраивало -- а некоторые считали что всё это плохо, и что канонично только генерить данные.

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

Я так чтоб "часто" такой отмазки не встречал. Отмазка какая-то негодная.

Не скажу что так чтоб точно процитирую "классиков и авторитетов", но мысль о том что "если код не тестируем, то он плохо написан" довольно популярна.