Size: a a a

2020 April 22

S

Sergei in atinfo chat
Valerian Zakaraya
Вот только как теперь понять, какая версия pytest подходила к этому плагину
2.7.3
источник

ŚW

Świętomierz Wisniewski in atinfo chat
Или вот так))
источник

S

Sergei in atinfo chat
источник

S

Sergei in atinfo chat
самое простое посмотреть депенденси)
источник

VZ

Valerian Zakaraya in atinfo chat
ох, попробую, спасибо
источник

VZ

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

S

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

VZ

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

VZ

Valerian Zakaraya in atinfo chat
Всякие verbose и прочее это не отображают
источник

MA

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

IB

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

DD

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

MA

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

IK

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

IK

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

DD

Dina Draguzya in atinfo chat
Maksim Andryushchenkov
Кстати если есть ответ на этот вопрос в книгах/статьях - скиньте плиз, очень интересно. Ибо часто бывает так, что разрабы открещиваются от юнит тестов, мол такую сложную бизнес логику не проверить в юнитах, ее надо пилить именно в апи тестах. Но по сути своей эти проверки сложности логики могут быть реализованы в юнит тестах более раздроблено так, что и апи тесты писать не придется. Может я и не прав, конечно.
в этой ситуации соглашусь с вашими разработчиками, у меня  такое же видение(по крайней мере, это справедливо для текущего проекта). возможно, если они не хотят писать юнит, их можно привлечь к интеграционным?)
источник

S

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

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

R(

Roman (rpwheeler) in atinfo chat
Maksim Andryushchenkov
Товарищи, есть вопрос и возможно он холиварный, но интересно ваше мнение. Все мы проверяем логику приложения в апи тестах, геты, сеты, возможно в базу кто-то лезет с проверкой после запроса апи. Как определить ту грань, при которой реализация проверки бизнес логики превращается в повторение кода приложения, но уже в самом тесте? И правильно ли это?
Он холиварный, конечно, но (и) с другой стороны.

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

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

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

S

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

R(

Roman (rpwheeler) in atinfo chat
Maksim Andryushchenkov
Кстати если есть ответ на этот вопрос в книгах/статьях - скиньте плиз, очень интересно. Ибо часто бывает так, что разрабы открещиваются от юнит тестов, мол такую сложную бизнес логику не проверить в юнитах, ее надо пилить именно в апи тестах. Но по сути своей эти проверки сложности логики могут быть реализованы в юнит тестах более раздроблено так, что и апи тесты писать не придется. Может я и не прав, конечно.
Я так чтоб "часто" такой отмазки не встречал. Отмазка какая-то негодная.

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