t.me/atinfo_chat Telegram группа по автоматизации тестирования

Какой-нибудь инструмент для отслеживания изменений в HTML

dom
tools
Теги: #<Tag:0x00007f21d345ade8> #<Tag:0x00007f21d345abb8>

(Алексей Павлов) #21

Ну это просто был пример ситуации… Всё бы изменилось, если бы речь шла о другом hidden-элементе, который не принимает текстовое значение (может это какой-то чекбокс true/false, как Вы по значению такой отыщете? Этих true/false может быть миллион в исходнике). Повторюсь, примеров у меня много отчего назрела мысль топика, потому что для каждого из примеров искать пути решения конечно можно, но удобнее и проще было бы какой-нибудь монитор изменений в HTML найти, чтобы не заморачиваться… Что-нить типа браузера, в котором выполняешь действия, а любые изменения в HTML, происходящие после действия, высвечиваются списком с конкретным местом локализации что и где изменилось. Если таких тулз в принципе нет, то в общем-то вопрос темы можно считать закрытым. Хотя подождём, может кто знает что-то подобное.


(Alexandr D.) #22

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


(Алексей Павлов) #23

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


(Алексей Павлов) #24

И, кстати, все примеры, которые я озвучил выше - практические.


(Alexandr D.) #25

Что-то я там ни одного куска HTML кода не видел, одни слова.


(Алексей Павлов) #26

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


(Alexandr D.) #27

Тогда это вам в гугле надо искать такие тулзы.
Но всё равно мне видится это немного странным. Почти всё можно решить селениумом или JS.


(Алексей Павлов) #28

Даже если можно - вопрос как минимум в скорости. То что я буду решать селениумом или JS, может занять в 5 раз больше времени, чем быстрый мониторинг изменений.
Плюс удобство.


(Алексей Павлов) #29

А в Гугле поверхностно искал - не нашёл… Да и запрос трудно адекватно сформулировать.


(Alexandr D.) #30

Достаточно один раз написать метод расширения (или его аналог) и пользоваться им. :slight_smile:


(asolntsev) #31

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


(Алексей Павлов) #32

Нет, не правильно.
Подробности - в теме.


(Vladislav Abramov) #33

вам с самого начала написали, что вы хотите сами не знаете чего

и ровно поэтому не можете сформулировать вопрос для Гугла и найти то, что же именно вам нужно


(Sergei) #34

@asolntsev да здесь в очередной раз пример неправильной организации тестирования на уровне проекта и скорее всего компании в целом, даже забавно что целое полотно с комментами образовалось, @BlastBox не в обиду вам. Вы лишь заложник ситуации, который пытается решить местечковую проблему. А глобальная проблема в том, что селениумные тесты для общих сценариев, и не таким топорным инструментом тестировать такие тонкие материи как появление/скрытие иконок, отслеживать какие-то минорные изменения в доме. Селениум не может отслеживать браузер в режиме реального времени. Такие тонкости тестируются интеграционно, возможно даже вообще без привлечения браузера, на уровне кода и моков, зачастую девами. Но когда нет юнитов и интегралов на достаточном уровне, то пытаются закрыть дыры магией селениума, грусть.


(Алексей Павлов) #35

Читайте внимательнее - будет ясно чего я хочу. Если не понимаете - лучше промолчать.
Запрос в Гугл не могу сформулировать не по этой причине, не надо додумывать.


(Viktor) #36

К сожалению прелоадеры не всегда блокируют доступ к элементу, поэтому иногда их приходится ждать


(Михаил Братухин) #37

Получилось что-то отловить через getPageSource?


(Алексей Павлов) #38

Пока не пробовал. Вопрос не актуальный для меня прямо на текущий момент, он скорее на будущее.


(Сергей Слётов) #39

На сколько известно, специального инструмента нет.

У меня есть идеи на этот счёт:
напишите специальный класс-провайдер работы с WebDriver (пример для Java), который работает с WebDriver.
Например:

public class WebDriverProvider {
   WebDriver wd;

   public workWithWebDriver(WebDriverAction action){
      String before = wd.getPageSource(); // HTML до
      action.doAction(wd);
      String after = wd.getPageSource(); // HTML после
      // тут уже сравниваем ДО и ПОСЛЕ
      // Можно добавить ожидание изменения текста (ждём пока ДО и ПОСЛЕ равны)
   }

   @FunctionalInterface
   protected interface WebDriverAction {
      void doAction(WebDriver wd);
   }
}

Используем так:

// всякие настройки
WebDriver myWD = new КакойТоДрайвер();
WebDriverProvider wdp = new WebDriverProvider(WebDriver myWD);
wdp.workWithWebDriver(wd -> {
   WebElement we = wd.findElement(...);
   we.click();
})

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


(Алексей Павлов) #40

Спасибо, посмотрю этот вариант позже