вы уверены что он подтягивает его при запуске через тим сити?

plugin от maven?

я не работал с тим сити, но у дженкинса под каждый билд свое окружение

я не работал с тим сити, но у дженкинса под каждый билд свое окружение

Интересно, но история выше с тестом в домашних условия в рамках двух ПК интересна

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

сравнивайте окружения

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

Спасибо, попробую копнуть в эту сторону

Selenoid = selenium поконфортней?

Обычно где?

зависит от компании, да - но много где так ?

зависит от компании, да - но много где так ?

Я бы даже повторил свой вопрос про "где", но кажется это бессмымсленно.

)) например в Яндексе

Нет, в Яндексе такого нет, например.

Всем привет Есть тесты на testNG, разбиты на 2 сюита: testng1.xml и testng2.xml. Вопрос: Как запустить выполнение этих сюитов параллельно с помощью ТимСити и gradle?

Нет, в Яндексе такого нет, например.

видимо, зависит от команды ? не всегда это совсем официально

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

ок, готов согласиться

Всем привет Посоветуйте open-source платформу для ведения тест-кейсов и test-runs. Хочется чтобы была интеграция с Jira, отчеты, возможность выводить результаты автотестов

Привет всем! закралась мысль в голову, попробовать замутить e2e тесты, на данный момент использую (Java + junit + maven). Вопрос можно ли как то запускать Jar файлы что бы иметь e2e тесты?)

Привет. Кто поднимал magento 2 та nginx ?

Всем привет! На интервью неоднократно встречался такой вопрос: на бэкенде есть сервис, он общается с 4 другими сервисами и с бд напрямую, как его тестировать. Я отвечал что-то в духе сначала работу самого сервиса с заглушками моками и тд, помимо функционального можно безопасность, перфоманс и тд проверять, здесь же проверить работу сервиса с бд, затем если есть возможность, поочередно интегрировать его с другими сервисами и проверять в связке, ну и системное наконец. Ответ, насколько я мог судить, не зашел и, если у кого-то есть время, может рассказать правильный ответ или посоветовать что почитать?

Имхо вопрос изначально поставлен некорректно, так что твой ответ я бы принял, так ты в целом рассказал все виды тестирования

Юнит, интеграционные, нагрузочное, секурити и е2е

Всем привет! На интервью неоднократно встречался такой вопрос: на бэкенде есть сервис, он общается с 4 другими сервисами и с бд напрямую, как его тестировать. Я отвечал что-то в духе сначала работу самого сервиса с заглушками моками и тд, помимо функционального можно безопасность, перфоманс и тд проверять, здесь же проверить работу сервиса с бд, затем если есть возможность, поочередно интегрировать его с другими сервисами и проверять в связке, ну и системное наконец. Ответ, насколько я мог судить, не зашел и, если у кого-то есть время, может рассказать правильный ответ или посоветовать что почитать?

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

А что мешает самому перед ответом задать вопросы, которые тебя смущают, например?

Это, пожалуй, первое, чего я ожидал бы от кандидата в ответ на такой вопрос.

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

Это, пожалуй, первое, чего я ожидал бы от кандидата в ответ на такой вопрос.

Довольно странная позиция задавать некорректный вопрос чтобы ждать на него уточняющие ответы

Вопрос более чем корректный.

Тогда и ответ корректный

Nope.

Какой вопрос такой ответ

Довольно странная позиция - это ожидать, что тебе на собеседовании будут задавать вопросы, имеющие только один правильный ответ, детально расписаные и разжеванные.

Возможно тема для флуда, но разве не было ещё идеи тренировочных собесов?

На уровне комьюнити

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

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

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

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

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

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

А на что влияет ЯП сервисов? На что влияет api, в плане того что это же просто средство общения между/с сервисами? С цепочкой или хаотическим общением хороший вопрос, не помню задавал ли его. Моки нужны, тк задание проверить один сервис вообще, просто он общается с другими.

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

Да, ЯП вообще ни на что не влияет

в проверке

СУБД с ЯП - это как небо и землю сравнивать

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

все эти вопросы надо задавать после вопросов интервьюера, когда хочешь узнать что за проект и как он устроен

Довольно странная позиция задавать некорректный вопрос чтобы ждать на него уточняющие ответы

Серьезно? Даже от джунов ожидают правильных вопросов так то - что на собесе, что в работе

я имею ввиду такие вопросы, на которые хочется спрашивать а вы это хотите услышать или это?

в целом ответ необходимый и достаточный

А на что влияет ЯП сервисов? На что влияет api, в плане того что это же просто средство общения между/с сервисами? С цепочкой или хаотическим общением хороший вопрос, не помню задавал ли его. Моки нужны, тк задание проверить один сервис вообще, просто он общается с другими.

1) ЯП - как минимум вы расскажите как питон сервисы тупят по перформансу в кубернетесе и что нужно переписать его на golang ;) 2) вам общаться с этим API, клиентским приложениям общаться с этим API. Его реализация влияет очень на многое. 3) Вы реально думаете, что замочив сервис второго уровня, вы не пропустите баг в интеграции с ним? Вы можете сразу тестировать end2end и смотреть как сервисы дружат. А вот в случае с тестированием внешней интеграцией я думаю кейс с моками более удобоварим 4) СУБД влияет на то, как хранятся данные, как быстро их можно вытащить (странно если сервис с нагрузкой в 20000 rps будет ходить каждый раз в postgresql или mysql). Ну и тем более вам валидировать данные, которые попадают в эту базу. 5) Про кеширование кстати можно было бы еще спросить.

1) ЯП - как минимум вы расскажите как питон сервисы тупят по перформансу в кубернетесе и что нужно переписать его на golang ;) 2) вам общаться с этим API, клиентским приложениям общаться с этим API. Его реализация влияет очень на многое. 3) Вы реально думаете, что замочив сервис второго уровня, вы не пропустите баг в интеграции с ним? Вы можете сразу тестировать end2end и смотреть как сервисы дружат. А вот в случае с тестированием внешней интеграцией я думаю кейс с моками более удобоварим 4) СУБД влияет на то, как хранятся данные, как быстро их можно вытащить (странно если сервис с нагрузкой в 20000 rps будет ходить каждый раз в postgresql или mysql). Ну и тем более вам валидировать данные, которые попадают в эту базу. 5) Про кеширование кстати можно было бы еще спросить.

опять же это все не относится к вопросу "как вы будете тестировать сервис"

опять же это все не относится к вопросу "как вы будете тестировать сервис"

Простите, а как вы будете его тестировать? :)

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

далеко не факт что они спрашивают про свое приложение или сервис

что у них именно так

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

так как бы Вы тестировали такую систему микросервисов, если ЯП, СУБД, API и другая информация вам не нужны?

чем мое сообщение что такой ответ я принимаю не отвечает на вопрос как я буду его тестировать?

считайте что все перечисленное я покрою автотестами

ок

@azshoo да, на пайтесте

@azshoo да, на пайтесте

Чего?

#простите )

1) ЯП - как минимум вы расскажите как питон сервисы тупят по перформансу в кубернетесе и что нужно переписать его на golang ;) 2) вам общаться с этим API, клиентским приложениям общаться с этим API. Его реализация влияет очень на многое. 3) Вы реально думаете, что замочив сервис второго уровня, вы не пропустите баг в интеграции с ним? Вы можете сразу тестировать end2end и смотреть как сервисы дружат. А вот в случае с тестированием внешней интеграцией я думаю кейс с моками более удобоварим 4) СУБД влияет на то, как хранятся данные, как быстро их можно вытащить (странно если сервис с нагрузкой в 20000 rps будет ходить каждый раз в postgresql или mysql). Ну и тем более вам валидировать данные, которые попадают в эту базу. 5) Про кеширование кстати можно было бы еще спросить.

Спасибо) про ЯП это, кнч, мощно, но вопрос скорее был бы актуален если бы на стадии документации, еще до реализации его задавать. Если сервис написан то тестировать придется то что есть. С API вопрос тоже, мне кажется, влияет уже на какие-то технические аспекты, а по факту какое-бы API не было, нужно проводить контрактное тестирование, поправьте если ошибаюсь. 3) если я добросовестно замочил сервис и проверил все запросы и ответы своего сервиса и другой тестировщик добросовестно замочил мой сервис и проверил запросы ответы по спеке, то если убрать всякие непредвиденные обстоятельства, все должно быть при интеграции хорошо. Все предусмотреть, кнч, нельзя и от багов не спасет, но их будет меньше и разбираться че там не так тоже будет легче. 4) тоже похоже на техничнский вопрос, я так понимаю, все таки хотели услышать общую логику тестирования без подобных практических углублений. А может и нет)

Спасибо) про ЯП это, кнч, мощно, но вопрос скорее был бы актуален если бы на стадии документации, еще до реализации его задавать. Если сервис написан то тестировать придется то что есть. С API вопрос тоже, мне кажется, влияет уже на какие-то технические аспекты, а по факту какое-бы API не было, нужно проводить контрактное тестирование, поправьте если ошибаюсь. 3) если я добросовестно замочил сервис и проверил все запросы и ответы своего сервиса и другой тестировщик добросовестно замочил мой сервис и проверил запросы ответы по спеке, то если убрать всякие непредвиденные обстоятельства, все должно быть при интеграции хорошо. Все предусмотреть, кнч, нельзя и от багов не спасет, но их будет меньше и разбираться че там не так тоже будет легче. 4) тоже похоже на техничнский вопрос, я так понимаю, все таки хотели услышать общую логику тестирования без подобных практических углублений. А может и нет)

Мне кажется когда нанимают человека на работу, от него хотят в первую очередь именно практических навыков. То есть чтение логов, манипуляция с базами, крафт запросов к апи и вот это вот все. Что касается интеграции, то нет: замокать и протестить два сервиса без проверок интеграции очень рискованно, на мой взгляж

То есть моя мысль в том, что нужно наличие трёх пунктов: 1) понимание бизнес логики, заложенной в сервис 2) понимание архитектуры сервиса 3) наличие навыков для работы с сервисом.

pytest-ом вообще можно совсем всё тестировать?

pytest - это просто фреймворк для ваших тестов, написанных на python.

Я pytest использовал, но только для юнит-тестов своего же кода на python-e

Не хватает воображения, чтобы представить как им можно тестировать всё.

Посоветуйте по каким ключевым словам поискать материал для самообразования

Это просто запускалка тестов.

Можно хоть обучение нейросеток на нем запускать, при желании.

Посоветуйте по каким ключевым словам поискать материал для самообразования

Наверное, все читали это: https://m.habr.com/company/yandex/blog/242795/

Разворачивание операционок в кастомное конференциях тоже можно с помощью pytest делать?

Спасибо за ссылку.

это же просто удобный враппер над юниттестом и все

Я наверное плохо сформулировал. Когда/для каких гвоздей в автоматизации тестирования стоит использовать pytest, а в каких случаях надо его отложить в сторону и брать что-то другое. Как понять?

выше уже ответили. у меня на пайтесте построено все тестирование, ручных тестеров нет

что вы будете из него дергать - вопрос того как вы заимплементите

у меня поднимается и тестируется по 10 приложений с разными бд и nginx в каждом потоке

а что другое в пайтоне брать?)

nose?)

Не-не

pytest лучшее...

А что за веяние, тестирование на golang?

Там вроде не про *тестирование* на го, а про переписывание сервисов на го

Там вроде не про *тестирование* на го, а про переписывание сервисов на го

Нет, именно тестирование. Не знаю, где «там» но я уже не от одного лида слышу о тестах на го