Size: a a a

2019 November 06

KK

Kirill (Cykooz) Kuzminykh in rannts
Ещё там REST называется "архитектурным стилем"
источник

KK

Kirill (Cykooz) Kuzminykh in rannts
источник

БС

Байт Словович in rannts
Roman Bolkhovitin
Как называеца?
источник

RB

Roman Bolkhovitin in rannts
Очень симпатично
А firefox не нужен?

Currently, only browsers in the Chrome family are supported
источник

БС

Байт Словович in rannts
я честно говоря не знаю, ибо не моя респонсибилити. Но той боли что была в других проектах с силениум, тут нет. тесты пишут на js, пишут они красиво, без того неподдерживаемого силеневского говна. можно сконфигурить так, что упавшие тесты видео публишили в CI.
источник

AB

Andrei Burakov in rannts
А поддержка загрузки файлов есть?
источник

R

Roman in rannts
Andrei Burakov
А поддержка загрузки файлов есть?
источник

AB

Andrei Burakov in rannts
Спасибо
источник

ND

Nick Demidov in rannts
#whois
Я, Николай, Джун-питонщик, пишу автотесты)
источник

💭П

💭 Руслан Прохоров in rannts
Nick Demidov
#whois
Я, Николай, Джун-питонщик, пишу автотесты)
Вэлком
источник

ND

Nick Demidov in rannts
Пассибо)
источник

SZ

Sergey Z in rannts
ой а поясните мне за тесты.
вчера был спор, я (в силу лени и того что я всё-таки не тестировкщик) пишу только тесты проверяющие успех, и эти тесты интеграционные, всю систему в нескольких сценариях проверяют.

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

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

вы как-нибудь решаете такое?
источник

RM

Roman Makhlin in rannts
Sergey Z
ой а поясните мне за тесты.
вчера был спор, я (в силу лени и того что я всё-таки не тестировкщик) пишу только тесты проверяющие успех, и эти тесты интеграционные, всю систему в нескольких сценариях проверяют.

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

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

вы как-нибудь решаете такое?
решаю очень просто - есть стандартный набор ошибок, которые прописаны в дизайне или еще там где то и их и покрываю, как тесты на не успех
источник

RM

Roman Makhlin in rannts
ну типо - пользователь запросил то, что ему низя, пришел отказ
отвалилось что то по таймауту и мы это как то обработали, ну все в таком духе, что вроде как адекватно и случается
источник

RM

Roman Makhlin in rannts
специально фантазировать на тему того, где кто может ошибится, имхо плохая практика и путь в никуда, все равно люди ошибаются не там, где ожидаешь иначе бы у нас все было саломой застеляно давно
источник

SZ

Sergey Z in rannts
мммм, попробую объяснить мой случай.
допустим у меня есть 4 шага, которые пользователь должен пройти чтоб получить результат.
каждый шаг - микросервис, которые может возвращать какие-то свои ошибки.
например каждый микросервис возвращает 2 ошибки.

тогда на шаге
1 - надо проверить 3 сценария
на шаге
2 - надо проверить уже 9 сценариев
на третьем и дальше уже совсем невозможное количество вариантов
источник

RM

Roman Makhlin in rannts
может ну их, эти тесты? отдел тестирования то зачем тогда?
источник

SZ

Sergey Z in rannts
вот я проверяю только линейный успешный ход, и ошибки у меня в сценарии не учитываются вообще никак.
интересно как их туда занести так, чтоб не стало грустно
источник

SZ

Sergey Z in rannts
отдел тестирования пока что даже до моего понимания вопроса не дорос, надо помогать ребятам же
источник

RB

Roman Bolkhovitin in rannts
а почему такая математика? у тебя пользователь после ошибки на первом микросервисе все равно во второй попадает?
источник