SV
Небольшой вопрос по неймингу тестов, как все-таки правильно?
Анонимный опрос
57%
testArchiveDeposit
43%
archiveDepositTest
офигеть)
Size: a a a
2020 August 09
OR
Небольшой вопрос по неймингу тестов, как все-таки правильно?
Анонимный опрос
57%
testArchiveDeposit
43%
archiveDepositTest
shouldArchiveDepositIfLoggedIn
IS
canArchiveDepositeWhenAuthorized
IS
или логин
СС
офигеть)
А где вариант test_archive_deposit?
I
А где вариант test_archive_deposit?
слишком просто))
EK
Привет!
Не могу импортировать python библиотеку в файл с тестами robotframework. Лежит в той же папке, что и тесты. Название файла имеет вид: AdminPage.py,
импортирую так:
В самой python библиотеке импортирую from robot.api.deco import library, keyword
Потом на методы указываю декораторы @keyword
И прописываю scope:
Когда в файле robot, хочу эту библиотеку использовать, то не видит robot питоновские keyword, а при выделении наименования библиотеки получаю сообщение «cannot find declaration to go»
Не могу импортировать python библиотеку в файл с тестами robotframework. Лежит в той же папке, что и тесты. Название файла имеет вид: AdminPage.py,
импортирую так:
Library AdminPage.py
В самой python библиотеке импортирую from robot.api.deco import library, keyword
Потом на методы указываю декораторы @keyword
И прописываю scope:
ROBOT_LIBRARY_SCOPE = ‘GLOBAL’
Когда в файле robot, хочу эту библиотеку использовать, то не видит robot питоновские keyword, а при выделении наименования библиотеки получаю сообщение «cannot find declaration to go»
R
Привет!
Не могу импортировать python библиотеку в файл с тестами robotframework. Лежит в той же папке, что и тесты. Название файла имеет вид: AdminPage.py,
импортирую так:
В самой python библиотеке импортирую from robot.api.deco import library, keyword
Потом на методы указываю декораторы @keyword
И прописываю scope:
Когда в файле robot, хочу эту библиотеку использовать, то не видит robot питоновские keyword, а при выделении наименования библиотеки получаю сообщение «cannot find declaration to go»
Не могу импортировать python библиотеку в файл с тестами robotframework. Лежит в той же папке, что и тесты. Название файла имеет вид: AdminPage.py,
импортирую так:
Library AdminPage.py
В самой python библиотеке импортирую from robot.api.deco import library, keyword
Потом на методы указываю декораторы @keyword
И прописываю scope:
ROBOT_LIBRARY_SCOPE = ‘GLOBAL’
Когда в файле robot, хочу эту библиотеку использовать, то не видит robot питоновские keyword, а при выделении наименования библиотеки получаю сообщение «cannot find declaration to go»
И
У робота очень хорошая документация, рекомендую обратиться к ней
EK
У робота очень хорошая документация, рекомендую обратиться к ней
Читала, не выходит ничего, поэтому сюда пишу
MY
Господ и дамы, добрый вечер! Кто то использовал testconteiners для тестирования UI ? Хотелось бы знать в каких случаях целесообразно его использовать, кроме случая когда самому нужно кучу сервисов поднимать
EB
Имхо testcontainers бесполезное дерьмо.
Жил был docker-compose и у него была декларативная модель объявления сервисов, а потом джависты подумали, что было бы неплохо обернуть все это в ООП, и в твои тесты внести зависимости инфраструктуры (тесты не должны знать ничего о контексте инфраструктуры)
В итоге у тебя есть обертка, которая ограничена по функциональности оригинального решения, предлагает сомнительные решения по скалированию ресурсов (вместо горизонтального скалирования сервисов и микро инстансов в облаке, где удобно просто иметь разные докер-компоуз среды; тестконтейнерс предполагают, что у тебя есть Большой Сервер на котором должно крутиться N инстансов mysql) , ну и любой шаг влево-вправо потенциально рубит на корню идею, что тебе не нужно будет понимать как работает докер
Жил был docker-compose и у него была декларативная модель объявления сервисов, а потом джависты подумали, что было бы неплохо обернуть все это в ООП, и в твои тесты внести зависимости инфраструктуры (тесты не должны знать ничего о контексте инфраструктуры)
В итоге у тебя есть обертка, которая ограничена по функциональности оригинального решения, предлагает сомнительные решения по скалированию ресурсов (вместо горизонтального скалирования сервисов и микро инстансов в облаке, где удобно просто иметь разные докер-компоуз среды; тестконтейнерс предполагают, что у тебя есть Большой Сервер на котором должно крутиться N инстансов mysql) , ну и любой шаг влево-вправо потенциально рубит на корню идею, что тебе не нужно будет понимать как работает докер
AE
Имхо testcontainers бесполезное дерьмо.
Жил был docker-compose и у него была декларативная модель объявления сервисов, а потом джависты подумали, что было бы неплохо обернуть все это в ООП, и в твои тесты внести зависимости инфраструктуры (тесты не должны знать ничего о контексте инфраструктуры)
В итоге у тебя есть обертка, которая ограничена по функциональности оригинального решения, предлагает сомнительные решения по скалированию ресурсов (вместо горизонтального скалирования сервисов и микро инстансов в облаке, где удобно просто иметь разные докер-компоуз среды; тестконтейнерс предполагают, что у тебя есть Большой Сервер на котором должно крутиться N инстансов mysql) , ну и любой шаг влево-вправо потенциально рубит на корню идею, что тебе не нужно будет понимать как работает докер
Жил был docker-compose и у него была декларативная модель объявления сервисов, а потом джависты подумали, что было бы неплохо обернуть все это в ООП, и в твои тесты внести зависимости инфраструктуры (тесты не должны знать ничего о контексте инфраструктуры)
В итоге у тебя есть обертка, которая ограничена по функциональности оригинального решения, предлагает сомнительные решения по скалированию ресурсов (вместо горизонтального скалирования сервисов и микро инстансов в облаке, где удобно просто иметь разные докер-компоуз среды; тестконтейнерс предполагают, что у тебя есть Большой Сервер на котором должно крутиться N инстансов mysql) , ну и любой шаг влево-вправо потенциально рубит на корню идею, что тебе не нужно будет понимать как работает докер
:)
MY
Хмм, интересно)
OR
Имхо testcontainers бесполезное дерьмо.
Жил был docker-compose и у него была декларативная модель объявления сервисов, а потом джависты подумали, что было бы неплохо обернуть все это в ООП, и в твои тесты внести зависимости инфраструктуры (тесты не должны знать ничего о контексте инфраструктуры)
В итоге у тебя есть обертка, которая ограничена по функциональности оригинального решения, предлагает сомнительные решения по скалированию ресурсов (вместо горизонтального скалирования сервисов и микро инстансов в облаке, где удобно просто иметь разные докер-компоуз среды; тестконтейнерс предполагают, что у тебя есть Большой Сервер на котором должно крутиться N инстансов mysql) , ну и любой шаг влево-вправо потенциально рубит на корню идею, что тебе не нужно будет понимать как работает докер
Жил был docker-compose и у него была декларативная модель объявления сервисов, а потом джависты подумали, что было бы неплохо обернуть все это в ООП, и в твои тесты внести зависимости инфраструктуры (тесты не должны знать ничего о контексте инфраструктуры)
В итоге у тебя есть обертка, которая ограничена по функциональности оригинального решения, предлагает сомнительные решения по скалированию ресурсов (вместо горизонтального скалирования сервисов и микро инстансов в облаке, где удобно просто иметь разные докер-компоуз среды; тестконтейнерс предполагают, что у тебя есть Большой Сервер на котором должно крутиться N инстансов mysql) , ну и любой шаг влево-вправо потенциально рубит на корню идею, что тебе не нужно будет понимать как работает докер
Тест контейнерс полезны в интеграционном и компонентом тестировании систем и отдельных сервисов.
VP
Всем привет. Подскажите как сматчить 2 списка по id в один ?
I
что значит сматчить ? объединить имел в виду мб?
VP
имею ввиду что бы на выходе получил вот такой список :
DE
такой функции нет в java
с точки зрения java, у вас 4 разных объекта - то, что там idшники совпадают, ничего не значит
с точки зрения java, у вас 4 разных объекта - то, что там idшники совпадают, ничего не значит