Testy automatyczne - w czym Opcje

[Pyton_000]

Z racji tego że zmieniam trochę swój zawód to potrzebuję info w czym teraz się pisze testy automatyczne po stronie przeglądarki. Chodzi o coś pokroju Selenium.
Jest coś ciekawszego teraz? Dodam że teraz będę siedział więcej w Pythonie niż PeHaPie

Założenie jest takie żeby takie testy odpalić i niech latają sobie cały czas gdzieś tam na jakimś środowisku. Ma to na celu wykrycie ew. awarii np. jakiegoś zew. Api zanim klienci będą płakać.

Ten post edytował Pyton_000 1.07.2017, 11:32:07

[vokiel]

Możesz też użyć Chrome w trybie headless https://developers.google.com/web/updates/2...arma-mocha-chai

[Pyton_000]

Ooo dość ciekawe. Tylko tutaj może być problem z kompatybilnością z innymi przeglądarkami czy tak? Bo np. dobrze by było testować pod FF, IE, Chrome, Safari. Chyba że Headless ma taką możliwość.

[Comandeer]

Jak chcesz testować w wielu przeglądarkach, to być może zainteresują Cię usługi typu Sauce Labs lub BrowserStack

[nospor]

A czemu poprostu nie uzyjesz selenium o ktorym wspomniales na poczatku?

[Pyton_000]

@nospor nie po to zapytałem się o alternatywy Ja wiem że jest Selenium, ale może świat poszedł za czymś nowym jak Google za Kotlinem

@Comandeer Dzięki. Poczytam. W sumie to cross browsers chyba nie będzie top priorytetem, ale widzę że chyba oba odpalają testy Selenium. Więc wychodzi na to że Selenium jest jedyne rozwijane dobre rozwiązanie?

Ten post edytował Pyton_000 1.07.2017, 20:53:06

[nospor]

Ja wiem ze wiesz ze jest selenium. Toz sam o nim wspomniales na poczatku
Ja sie jedynie chcialem dowiedziec czemu nie chcesz go uzywac. Moze sa jakies konkretne powody - sam sie chetnie doksztalce

[Pyton_000]

No toć piszę że pytam czy jest może coś nowszego, lepszego, bardziej na topie

[mrc]

bardziej na topie

Ja uważam, że jeżeli jest Selenium, i daje Ci bezpieczeństwo i pewność* w testowaniu aplikacji, to po co szukać czegoś lepszego? W zasadzie chyba nic nowego w testowaniu zachowania aplikacji nie wynaleziono, więc ...

*Chyba, że Ci nie daje, to ok

Ten post edytował mrc 2.07.2017, 10:01:16

[Pyton_000]

Na razie mi nic nie daje bo jeszcze w nim nie pisałem Generalnie przechodząc do innego projektu moim zadaniem będzie napisanie testów tak aby pokryć maksymalnie aplikację, toteż dobór technologii mam dowolny.

[Lion]

Selenium jest fajne, chyba że masz na stronie dużo elementów ładowanych ajaxem. Dobrze jest wtedy móc to co przygotujesz w Selenium jeszcze oprogramować. Na chwilę obecnie brakuje w Selenium niestety dobrego formatera do kodu PHP. Musiałem sobie taki sam napisać. Generuje mi on kod w PHP wykorzystujący bibliotekę facebook/php-webdriver: https://github.com/facebook/php-webdriver.

[Pyton_000]

Możesz rozwinąć myśl z Ajaxem?

[Comandeer]

Jeśli nie chcesz Selenium, to szukaj innych bibliotek obsługujących standard WebDriver. Inna rzecz, że chyba wszyscy obecnie albo korzystają, albo wzorują się na Selenium

[Pyton_000]

Nie to że nie chcę. Pierwotnie w nim chciałem pisać testy. Ale kto nie szuka ten nie znajdzie. To trochę tak jak z PHP i FW. Wiem że mogę napisać projekt w SF3 ale mogę równie dobrze napisać go w Laravelu Efekt w obu przypadkach będzie taki sam.

[Comandeer]

Czy ja wiem? Projekt w SF zbierze mniej hejtu…

[nospor]

@Lion ja mam duzo ajax u siebie i nie mam problemu by testowac tego w selenium.
I co chodzi z tym formaterem php bo tez nie ogarniam

[Pyton_000]

@Comandeer eeetam Efekt uboczny Hejt dla mnie nie jest istotny Ot gadanie ludzi którzy z reguły nie mają nic do powiedzenia konstruktywnego.

[Lion]

Z ajaxem problem występuje podczas klikania i oczekiwania na odpowiedź. W Selenium mamy polecenia clickAndWait oraz click. Pierwsze z nich czeka na odpowiedź z serwera, drugie klika i przechodzi dalej, do kolejnego polecenia. Drugie bardziej nadaje się do obsługi ajaxa. Problem powstaje gdy odpowiedź ajaxowa przychodzi w losowym czasie a kolejne kroki testu od niej zależą. Można, co prawda, zastosować pause albo waitFor* ale to w aplikacji nad którą pracowałem nie dawało efektu bądź powodowało że czas pojedynczego testu wydłużał się do minut. Aplikacja działała w taki sposób, że w przypadku ISE odpowiedź i tak szła ajaxem tyle że powodowała wyrenderowanie czegoś zupełnie innego niż w przypadku pozytywnym. W tym negatywnym przypadku nie było sensu dalej czekać na timeout. Trzeba było zastosować pewne instrukcje warunkowe. Dodatkowym problemem okazały się timery ajaxowe i ogólna asynchroniczność aplikacji, należało się upewnić że odpowiedź jest odpowiedzią na którą czekamy.

Z powyższych powodów zdecydowałem się podrasowywać testy w PHP. Niestety, na chwilę obecną brakuje w Selenium IDE gotowego formattera do języka PHP do jakiegokolwiek frameworka testowego. Formatter to taki dodatek do Selenium (a właściwie do Firefoxa) który z domyślnego formatu Selenium (czyli HTML) tworzy kod w wybranym języku. Pisze się go, jak inne dodatki do FF, w JS. Formatery zainstalowane w Selenium można znaleźć w menu File > Export test case as.. Po napisaniu własnego powinien się on tam pokazać i umozliwić szybki eksport testu. Napisałem taki formater (przykłady jak to zrobić można znaleźć na GitHubie) który generuje kod PHP, klasę dziedziczącą po TestCase z PHPUnit, w której przy pomocy wcześniej wspomnianej biblioteki facebook/php-webdriver tworzone jest połączenie do serwera Selenium i wykonywane są testy. Wszystko dzieje się w środowisku headless kilku przeglądarek. PHPUnit zapewnia podstawowe asercje, można to uruchamiać z CLI tak jak inne suity PHPUnit, można podpiąć pod serwer CI, itp.

[Pyton_000]

No to zonk. Z tego co się orientuję w aplikacji którą będę testował jest caaałe mnustwo ajaxu a na dodatek wykresy które mogą się dość długo generować. Aplikacja jest napisana w Pythonie i tam też będę testy pisał.
Znalazłem też formattery do pythona: https://github.com/coUrbanize/selenium-python-formatters

To będzie ciekawe doświadczenie

[nospor]

@Lion faktycznie, z tym przypadkiem AJAX co opisales to prawda.
Ja to u siebie rozwiazuje tak, ze czekam x sekund lub do czasu az pojawi sie element generowany przez ajax - w zaleznosci co pierwsze nastapi. Poki co ladnie sie sprawdza.