B
Такое решается кастомными постоянными атрибутами
Size: a a a
2020 September 21
ES
В моём случае у меня был зловонючий элемент который в зависимости от своего состояния менял название одного из атрибутов, а значения атрибутов и другие имена атрибутов вообще каждый раз генерились разные. вот так я отловил ту часть его имени атрибута которая всегда была одинаковой.
Ext framework?
S1
это когда ты можешь потеребить разработчика и он умеет это делать. в данном случае этот атрибут генерирует фреймворк фронта и чтобы его поменять разработчику надо кое-что поделать вприсядку
ES
Такое решается кастомными постоянными атрибутами
Это если девы/тест менеджмент адекватные
B
Eugene Stogniy
Ext framework?
qooxdoo небось)
S1
Lwc фреймворк называется
S1
Lighting web components
YP
Всем привет.
Подскажите плиз если подобное было в практике или копать куда мне)
Можно как-нибудь получить контент этого элемента для выбора языка?
android.widget.LinearLayout
как видно, что внутри этого элемента нет вложенных элементов и не понимаю, как можно получить контент с названиями языков.
Подскажите плиз если подобное было в практике или копать куда мне)
Можно как-нибудь получить контент этого элемента для выбора языка?
android.widget.LinearLayout
как видно, что внутри этого элемента нет вложенных элементов и не понимаю, как можно получить контент с названиями языков.
R
Подскажите, в чем обычно/лучше хранить данные для параметризованных тестов. Порядок 6-10 полей на вход для 30-50 тест-кейсов, может быть больше, как и параметров, так и тест-кейсов. Сейчас все в ексель файлах. Колонки - входные параметры, строчки - тест-кейсы.
Если использовать json или yaml - не будут ли слишком длинные простынки в файлах? И хочется универсализма. Добавили параметр, и не надо добавлять пустое поле-значение для всего набора тест-кейсов (50+).
Народ хочет попроще редактировать, добавлять новые тест-кейсы, и хочется видеть изменения при pull/commit.
Если использовать json или yaml - не будут ли слишком длинные простынки в файлах? И хочется универсализма. Добавили параметр, и не надо добавлять пустое поле-значение для всего набора тест-кейсов (50+).
Народ хочет попроще редактировать, добавлять новые тест-кейсы, и хочется видеть изменения при pull/commit.
R(
Roman
Подскажите, в чем обычно/лучше хранить данные для параметризованных тестов. Порядок 6-10 полей на вход для 30-50 тест-кейсов, может быть больше, как и параметров, так и тест-кейсов. Сейчас все в ексель файлах. Колонки - входные параметры, строчки - тест-кейсы.
Если использовать json или yaml - не будут ли слишком длинные простынки в файлах? И хочется универсализма. Добавили параметр, и не надо добавлять пустое поле-значение для всего набора тест-кейсов (50+).
Народ хочет попроще редактировать, добавлять новые тест-кейсы, и хочется видеть изменения при pull/commit.
Если использовать json или yaml - не будут ли слишком длинные простынки в файлах? И хочется универсализма. Добавили параметр, и не надо добавлять пустое поле-значение для всего набора тест-кейсов (50+).
Народ хочет попроще редактировать, добавлять новые тест-кейсы, и хочется видеть изменения при pull/commit.
CSV. Текстовый формат представления табличных данных.
Просто экспортировать в него из экселя.
Просто экспортировать в него из экселя.
R(
> Добавили параметр, и не надо добавлять пустое поле-значение для всего набора тест-кейсов (50+).
CSV можно редактировать так же через эксель или опенофис.калк .
Проблема может быть только с чем-то нестандартным, что экселю может захотеться отформатировать. Но это будет видно в диффе.
CSV можно редактировать так же через эксель или опенофис.калк .
Проблема может быть только с чем-то нестандартным, что экселю может захотеться отформатировать. Но это будет видно в диффе.
i
> Добавили параметр, и не надо добавлять пустое поле-значение для всего набора тест-кейсов (50+).
CSV можно редактировать так же через эксель или опенофис.калк .
Проблема может быть только с чем-то нестандартным, что экселю может захотеться отформатировать. Но это будет видно в диффе.
CSV можно редактировать так же через эксель или опенофис.калк .
Проблема может быть только с чем-то нестандартным, что экселю может захотеться отформатировать. Но это будет видно в диффе.
csv можно в Идее редактировать как таблицу, она более бережно обращается с контентом
LY
Roman
Подскажите, в чем обычно/лучше хранить данные для параметризованных тестов. Порядок 6-10 полей на вход для 30-50 тест-кейсов, может быть больше, как и параметров, так и тест-кейсов. Сейчас все в ексель файлах. Колонки - входные параметры, строчки - тест-кейсы.
Если использовать json или yaml - не будут ли слишком длинные простынки в файлах? И хочется универсализма. Добавили параметр, и не надо добавлять пустое поле-значение для всего набора тест-кейсов (50+).
Народ хочет попроще редактировать, добавлять новые тест-кейсы, и хочется видеть изменения при pull/commit.
Если использовать json или yaml - не будут ли слишком длинные простынки в файлах? И хочется универсализма. Добавили параметр, и не надо добавлять пустое поле-значение для всего набора тест-кейсов (50+).
Народ хочет попроще редактировать, добавлять новые тест-кейсы, и хочется видеть изменения при pull/commit.
в yaml есть якори, можно не дублировать повторяющиеся значения
R
Интересно, надо глянуть. Раньше пользовались csv еще во времена когда Watir был популярен. Но напрягали заморочки опенофиса - сам лепил форматирование или кавычки везде, или цифры как даты решал. Следить приходилось постоянно после открытия...
S1
Так это проблемы опенофиса, а не csv же.
R
в yaml есть якори, можно не дублировать повторяющиеся значения
Про якори знаю, но все равно спасибо. Но в большинстве случаев параметры отличаются полностью..
R
То есть в идее можно редактировать аккуратно?
BO
Roman
То есть в идее можно редактировать аккуратно?
это зависит только от тебя.