Похоже на поиск серебряной пули вместо учета конкретных обстоятельств :) (в одной из сцен Men in Black II, где подземный червь Джеф откусывает часть вагона метро, вообще решили, что на тот момент дешевле и реалистичнее просто раздавить его (вагон) гидравлическим прессом)
Возможно, при следующем рефакторинге из примера выше стоит поработать над магическими числами? А то так можно вечно обновлять циферки то в коде, то в тестах.
Я тоже периодически "проводил" (невольно) подобные исследования ML-моделей: увлекаясь чем-то, долгое время не переключал треки в "потоке рекомендаций" музыкальных сервисов, в итоге на следующий день/в начале новой недели алгоритмы, обучаясь на собственных же рекомендациях, классифицировали меня как фаната чешского панк-рока, филиппинской попсы и этнических завываний :) /s
9.1. Можно сделать приоритетным запуск "smoke-группы" тестов — если они упадут, значит, у вас всё плохо, и ещё быстрее станет ясно, что нет смысла запускать остальные автотесты.
так кто вам гарантирует что при изменение верстки тот кто верстал не посносил data-testid
я специально вроде в скобках написал, что не всегда есть гарантия, но некоторую защищенность в этом плане может обеспечить, например, использование библиотеки компонентов, где data-testid прописан именно для компонентов, а не только в верстке.
Чем предложенный вами data-testid отличается от обычного id
лично я ничего не предлагал, но у меня есть ответ: в некоторых популярных фронтенд-фреймворках id может быть автогенерируемым (возможно, чтобы избежать использования кеша для старых стилей, но это не точно)
PS: Глядя на комментарии под статьей, хочу акцентировать, что нигде не писал такие фразы, как "нужно так делать" и "всем 100% подойдет этот подход" :)
Куда бы ни был инкапсулирован локатор, тесты все равно упадут, если произойдут озвученные риски (смена верстки итд, но и с "data-testid" оно может упасть при кардинальных изменениях, если уж на то пошло).
Конечно лучше быть здоровым и богатым, чем больным и бедным (с), но ждать "готовности" фронта можно долго, т.к. такие доработки обычно не в приоритете, но основная цель тестов -- помогать в обнаружении ошибок/экономить время на регресс, а не быть написанными на века, поэтому оптимальнее их все-таки создать раньше и на том, что есть, а потом обновить локаторы, все-таки их правка занимает меньше 5% от времени на разработку тестов.
Или я не так объяснил, или не так был понят, давайте на примере (искусственном, поэтому без вопросов к логике)): у вас есть страница покупок, где есть два списка: "купить" и "куплено", вам нужно проверить, что итем переехал из одного списка в другой, поэтому просто сверки по тайтлу будет мало, нужно еще учитывать родителя, тут одним лишь test-id не обойтись.
Локаторы есть, но у вас имеется структура элементов вида data-testid=my-list: data-testid=my-item, (где у каждого элемента в списке может быть ещё и data-testid=my-title, и вот по нему и надо найти)
Там указано, что это перевод, но видно, что скопировал (и не поправил ошибки типа отступов в питоне) человек, не знакомый с темой
Журналисты изнасиловали ученого, изнасиловавшего журналиста? :)
Океаны стали зеленее
Из-за человека гибнет планктон
Если где-то океан зелёный, там больше планктона
Не понял, как согласуются эти три пункта.
Похоже на поиск серебряной пули вместо учета конкретных обстоятельств :)
(в одной из сцен Men in Black II, где подземный червь Джеф откусывает часть вагона метро, вообще решили, что на тот момент дешевле и реалистичнее просто раздавить его (вагон) гидравлическим прессом)
Да, LED-панорамы круче, но дороже.
Возможно, при следующем рефакторинге из примера выше стоит поработать над магическими числами? А то так можно вечно обновлять циферки то в коде, то в тестах.
Потому что всё обычно заканчивается этим
Забыли еще, как минимум, несколько шагов:
Внедрение метрик для выявления проблем при/после деплоя
Автоматизация отката релизов (наличие автоматизации деплоя также подразумевается)
Автоматический откат релизов
с такими тестами легко разобраться — бегите оттуда, если не можете изменить эту ситуацию)
(но вообще имелось в виду, что падение таких тестов останавливает весь прогон, т.е. релиз, или что-то там ещё, встаёт)
Я тоже периодически "проводил" (невольно) подобные исследования ML-моделей: увлекаясь чем-то, долгое время не переключал треки в "потоке рекомендаций" музыкальных сервисов, в итоге на следующий день/в начале новой недели алгоритмы, обучаясь на собственных же рекомендациях, классифицировали меня как фаната чешского панк-рока, филиппинской попсы и этнических завываний :)
/s9.1. Можно сделать приоритетным запуск "smoke-группы" тестов — если они упадут, значит, у вас всё плохо, и ещё быстрее станет ясно, что нет смысла запускать остальные автотесты.
я специально вроде в скобках написал, что не всегда есть гарантия, но некоторую защищенность в этом плане может обеспечить, например, использование библиотеки компонентов, где data-testid прописан именно для компонентов, а не только в верстке.
лично я ничего не предлагал, но у меня есть ответ: в некоторых популярных фронтенд-фреймворках id может быть автогенерируемым (возможно, чтобы избежать использования кеша для старых стилей, но это не точно)
PS: Глядя на комментарии под статьей, хочу акцентировать, что нигде не писал такие фразы, как "нужно так делать" и "всем 100% подойдет этот подход" :)
Это не новый атрибут, сам элемент не изменяется, меняется дерево -- элемент переезжает, меняя родителя (со списка "купить" на "куплено").
Про другой локатор -- я специально написал, что пример искусственный (но имеющий аналоги на практике, просто решил не усложнять лишними деталями)
А что, в линкедине действительно происходят важные "обсуждения в отрасли"? Где почитать?
потому что на веб-страницах обычно больше одной ссылки и их надо как-то различать?
Куда бы ни был инкапсулирован локатор, тесты все равно упадут, если произойдут озвученные риски (смена верстки итд, но и с "data-testid" оно может упасть при кардинальных изменениях, если уж на то пошло).
Конечно лучше быть здоровым и богатым, чем больным и бедным (с), но ждать "готовности" фронта можно долго, т.к. такие доработки обычно не в приоритете, но основная цель тестов -- помогать в обнаружении ошибок/экономить время на регресс, а не быть написанными на века, поэтому оптимальнее их все-таки создать раньше и на том, что есть, а потом обновить локаторы, все-таки их правка занимает меньше 5% от времени на разработку тестов.
Или я не так объяснил, или не так был понят, давайте на примере (искусственном, поэтому без вопросов к логике)): у вас есть страница покупок, где есть два списка: "купить" и "куплено", вам нужно проверить, что итем переехал из одного списка в другой, поэтому просто сверки по тайтлу будет мало, нужно еще учитывать родителя, тут одним лишь test-id не обойтись.
Знать xpath все равно стоит для случаев, когда:
Локатора ещё нет, а тесты нужны
Локаторы есть, но у вас имеется структура элементов вида data-testid=my-list: data-testid=my-item, (где у каждого элемента в списке может быть ещё и data-testid=my-title, и вот по нему и надо найти)
Отрицать != опровергнуть (доказать ложность, неверность чего-н.)
1) может, имеется в виду, что нет защиты от повторного получения вредоносного сообщения?
3) может, инфа о бэкдоре ушла не в те руки, его пофиксили и добавили новый? :)