да

.jenkins\plugins все это есть

они вроде как качаются но устанавливаются (

Плагины можно потом доставить

Там понягляднее будет

Ругается на высокую версию дженкинса, бред какой-то

Спасибо

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

Начать дебажить принтами и увидеть где трансформация происходит?

Там очень интересно получается: с одной стороны это спрингбуттест со всеми аннотациями, а с другой стороны там runwith(SpringPactRunner) и она сама еще и на котлине. Тестового метода как такового нет, все на аннотациях и магии спринговой держится, принты некуда особо впихнуть :(

Проверь курлом, а после пиши код

Привет, может кто сталкивался, с интеграцией DDT тестов с TestRail? (Selenium + C#):
В плане организации кода. Сейчас работает вариант без DDT подхода, когда в коде автотестов захардкожен id тест кейса в тестрейле, а обновление статуса в тестрейле происходит в shutdown методе.
Вариант с кастомным атрибутом и листенером для обновления статуса в ТестРейле по началу отмели из за DDT, т к с каждым прогоном должен обновлять разные тесты (заведомо с известными айдишками).

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


Была мысль класть айдишки тестов в файл с тестовыми данными, но вопрос насколько это адекватно для дальнейшей работы и поддержки

в интерфейсе после выбора файла отображается его путь? добавляется элемент может? что вообще происходит?)

Я уже вчера нашел способ используя js передать файл, спасибо :)
Если интересно, тут рабочий код https://stackoverflow.com/questions/43382447/python-with-selenium-drag-and-drop-from-file-system-to-webdriver

да, это был один из найденных вариантов тоже)
не стоит благодарности

Не очень понятно какая у вас структура тестов в тестрейле, это раз.

Мне не понятно ещё, как сам факт DDT тестов накладывает ограничения и диктует характер взаимодействия с тестрейл.

Структура - есть тест ран, в котором лежат тест кейсы соответствующие автотестам, статусы обновляем опираясь айди тест кейса, (а не айди теста в тест ране).

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

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

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

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

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

“LoginSuccessful<“Steve”,”AppleFTW”>” как пример части тайтла тест кейса который может сообщать о названии теста и наборе тестовых данных.

В общем я за авторасширение тестплана тест-кейсами после параметризации и коллекта тестов.

А что это даст в конечном итоге - все нагенерированные тест кейсы?

Да, в тестах именно параметризация используется