Wpis z mikrobloga

@kotoj:
Osobiście preferuję XPath selectory, bo są dla mnie czytelniejsze, przyjemniej się je pisze. No i mają trochę większe możliwosci (xpath functions), których nie ma w css selektorach bądź zupełnie mi się nie podobają.
Przykładowo zdecydowanie wolę korzystać z 'starts-with niż odpowiednika w css selektorze, który jest jednym znakiem (^), ale przez to widywałem sytuacje, kiedy było 'Dlaczego ten selektor znajduje element, chociaż nie powinien?', bo ktoś ten jeden znaczek przeoczył.
W kwestii wydajności też mogę bronić xpathów. Ponad dwa lata temu sam to mierzyłem. Napisałem prostą stronę, wrzuciłem na serwer, napisałem odpowiednio xpathy i css selektorzy, zapuściłem testy w pętli i po godzinie sprawdziłem wyniki. Xpathy okazały się wolniejsze o ok. 2-3%
Nim siękomuś wyda to dużo - jedyne co testy robiły to wyszukiwały elementy i klikały. Nie wpisywaly żadnego tekstu, strona działała błyskawicznie (brak JSa czy grafik), nie było żadnej wyszukiwarki, żadnego większego backendu, zapisywania do bazy, itp. Wszystko to sprawi, ze w produkcyjnej apce ten odsetek spadnie drastycznie (w końcu czymś innym jest opóźnienie 20 sekund gdy testy trwają 1000 sekund, a czymś innym jest takie samo opóźnienie gdy testy trwają kilka razy dłużej).
Choć ponoć w przypadku gdy testy lecą w headless browser ta różnica
  • Odpowiedz
  • 0
@kotoj xpath jako ostateczność przy braku innych unikalnych selektorow. Plusem xpatha jest to że jest a minusów całkiem sporo zaczynając od performance
  • Odpowiedz
W kwestii wydajności też mogę bronić xpathów. Ponad dwa lata temu sam to mierzyłem. Napisałem prostą stronę, wrzuciłem na serwer, napisałem odpowiednio xpathy i css selektorzy, zapuściłem testy w pętli i po godzinie sprawdziłem wyniki. Xpathy okazały się wolniejsze o ok. 2-3%


Może to był właśnie błąd, taki sam jaki popełnił autor na blogu: http://elementalselenium.com/tips/34-xpath-vs-css-revisited-2

Dopiero za trzecim razem napisał odpowiednie testy.
  • Odpowiedz