Привет, здесь есть кто-нибудь, участвующий в разработке emias.info ? ну или знающий такого человека хотел уточнить у них о разработки кое-какой фичи

https://hr.alfabank.ru/events/qachestvennoe-obschenie-piter

На этот раз качественно общаться будем в СПБ! Приходите!

Делаю интеграцию с TestRail автотестов, написанных с помощью JUnit. Хочу после выполнения каждого теста пушить его результат (pass или fail) в соответствующий тест-кейс в тест-ране TestRail'а. Для меня видится логичным реализовать это в @After. Как можно в @After узнать, выполнился ли или упал текущий тест? Или, может, мой подход неправильный, и задачу можно решить другим способом?

А не логичнее ли это делать в ассерте теста?

@pavelnazimok сделай Rule для такой вещи

наследуешься от TestWatcher и описываешь себе колы в тестрейл

@newromka спасибо, попробую

А не логичнее ли это делать в ассерте теста?

не очень понимаю, как сделать это в ассерте

не очень понимаю, как сделать это в ассерте

Давно не копался в жюните, но первый результат в гугле показывает примерно так: https://stackoverflow.com/questions/5423625/intercepting-junit-assert-functions

@azshoo спасибо, буду пробовать :)

Гуру спецы по TestNG+selenium подскажите как в TestBase отлавливать упавший тест? и если есть листерены по мимо дефолтного тоже был бы рад

https://xakep.ru/2018/08/07/more-bugs-less-exploits/

https://xakep.ru/2018/08/07/more-bugs-less-exploits/

Это не баг, это баг

привет Бот. Как

Ребята, кто-нибудь уже решил идти на SQA Days 24, программы можно сказать нет, стоит ли?

Ребята, кто-нибудь уже решил идти на SQA Days 24, программы можно сказать нет, стоит ли?

Стандартный ответ на твой вопрос: зависит от того, что вы рассчитываете получить от посещения конфы.

Ребята, кто-нибудь уже решил идти на SQA Days 24, программы можно сказать нет, стоит ли?

23 была вообще ни о чем, максимум для новичков. имхо

Ребята, кто-нибудь уже решил идти на SQA Days 24, программы можно сказать нет, стоит ли?

стоит, но лучше подкиньте монетку

Ребята, кто-нибудь уже решил идти на SQA Days 24, программы можно сказать нет, стоит ли?

стоит, конечно

А не логичнее ли это делать в ассерте теста?

Логичнее это делать в CI

Логичнее это делать в CI

Что бы что?

Что бы что?

В Дженкинсе есть плагин который умеет в тестлинке тесты отмечать pass или fail плюс репорт прикладывать. Для test rail тоже есть наверное

В Дженкинсе есть плагин который умеет в тестлинке тесты отмечать pass или fail плюс репорт прикладывать. Для test rail тоже есть наверное

То, что есть плагин - не значит, что обязательно его надо использовать. А ещё CI - это не обязательно дженкинс. А запуски тестов, требующие тестрана и результатом - не обязательно через CI.

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

То, что есть плагин - не значит, что обязательно его надо использовать. А ещё CI - это не обязательно дженкинс. А запуски тестов, требующие тестрана и результатом - не обязательно через CI.

Ну я и не говорю что обязательно, говорю что логичнее

И почему это логичнее, чем прямая связь между тест-кейсом и его имплементацией?

Спойлер: ответ "потому что есть плагин" - так себе ответ на этот вопрос.

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

Спойлер: ответ "потому что есть плагин" - так себе ответ на этот вопрос.

Пфф, ну ок

Делай как знаешь

Пфф, ну ок

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

И, более того, даже не факт что это быстрее\удобнее\стабильнее.

Так дело не в плагине, дело что в коде жёстко прописывается связь с tms

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

И в случае чего в коде менять придется

Сейчас QA=DevOps

Дык, вынесите это в настройки

А так в настроечках

Я не уверен, что поправить линковку с тесткейсом в коде будет дольше\геморнее, чем в настроечках дженкинса.

Не говоря уж о том, что, как уже сказали выше, ничего не мешает вынести это в отдельную настройку\конфиг.

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

Ну если в тесте, тогда хоть листенером отлавливать

Океей, давайте на следующий круг: Чем это лучше, чем интерсепт ассерта?

а если unhandled exeption?

бить по рукам

плюс @after вроде бы выполняется в любом случае

Уйду в девопс там зп выше, а тут еще и тестирование))

а если unhandled exeption?

Вот это конструктивно.

а если unhandled exeption?

Таки, а какое у коробочного runListener ожидаемое поведение в данном случае?

он же крест показывает (error) вместо assert.fail

Хм, судя по тому что я бегло нагуглил за 15 минут, он просто фэйлится с пробросом экспешена в description.

Но я так себе эксперт в жюните.

Как запускать, последний вопрос который меня волнует))

Привет! Есть такие, кто использует c# + allure и пинает генерацию html репорта из кода по завершению тестов? Если есть расскажите как

Но я так себе эксперт в жюните.

Наверное использование плагина для Дженкинса имеет смысл, если одновременно используются тесты на разных стеках и не для всех из них можно проставлять результаты непосредственно в Тестрейл, а тут более-менее удобный костыль

это какие такие стеки не имеют curl ?

это какие такие стеки не имеют curl ?

assembler + pascal

assembler + pascal

Врете, на паскаль есть либкурль.

assembler + pascal

в асм и в паскаль можно дернуть 1. URLDownloadToFile https://msdn.microsoft.com/en-us/ie/ms775123(v=vs.94) 2. https://docs.microsoft.com/en-us/windows/desktop/WinInet/http-sessions

@qa_automation

Всем привет! А приходила ли кому-то в голову идея хранить тест-кейсы прямо в коде в виде, допустим, пустых автотестов, где будет только описание прекрндишена и шагов, а имплементацию завозить по мере необходимости? Чтобы в отчете при прогоне автотестов явно отличать неавтоматизированные и регрессить руками неавтоматизированное? И вообще, сталкивался ли кто-то с болью от синхронизации тестовой модели в тмс и приложения на проде? Есть предположение, что такая боль может быть актуальна только для больших продуктов, но это не точно

bdd вам в помощь

Возможно, но я простой разработчик, который в тестировании так себе. И если говорить про бидиди, то у меня возникает вопрос – почему тогда народ толпами пользуется tmsками вместо того, чтобы напиливать легко и весело bdd? Скорее всего я что-то не понимаю