Testowanie na frontach: co i jak testować i jakie narzędzie użyć?

Question

Piszę testy dla mojego kodu Ruby przez jakiś czas, ale jako programista frontendu jestem oczywiście zainteresowany wprowadzeniem tego do kodu, który piszę dla mojego kodu frontendowego. Jest sporo różnych opcji które zostały zabawy z:

• CasperJS
• Capybara & Rspec
• Jasmine
• ogórek lub po prostu rspec

Jakie są ludzie za pomocą dla testowania? A poza tym, co ludzie testują? Tylko JavaScript? Spinki do mankietów? Formularze? Hardcoded content?

Wszelkie przemyślenia będą mile widziane.

Answer 1

Istnieje wiele opcji i narzędzi do tego. Ale ich wybór zależy od tego, czy masz interfejs internetowy czy aplikację na komputery?

Przypuśćmy, że z narzędzi, o których wspomniałeś, jest to internetowy interfejs użytkownika. Sugerowałbym Selenium (aka WebDriver): http://seleniumhq.org/docs/

Istnieje wiele obsługiwanych języków (Ruby znajduje się na liście). Można go uruchamiać w różnych przeglądarkach, jest bardzo łatwy w obsłudze dzięki licznym samouczkom i wskazówkom. Och, i to oczywiście za darmo :)

Answer 2

Kilka miesięcy temu miałem te same pytania i po rozmowie z wieloma programistami i przeprowadzeniu wielu badań, dowiedziałem się o tym. Powinieneś przetestować swój JavaScript, napisać mały zestaw testów integracyjnych interfejsu użytkownika i unikać narzędzi do testowania rekordów i odtwarzania. Pozwól mi wyjaśnić to bardziej szczegółowo.

Najpierw należy wziąć pod uwagę test pyramid. To ciekawa analogia stworzona przez Mike'a Cohna, która pomoże ci zdecydować, jaki rodzaj testu powinieneś wykonać. Na dole piramidy znajdują się testy jednostkowe, które są solidne i zapewniają szybką reakcję. Powinny one stanowić podstawę twojej strategii testowej i tym samym zajmować największą część piramidy. U góry masz testy interfejsu użytkownika. Są to testy, które wchodzą w interakcję z twoim interfejsem użytkownika, jak na przykład Selenium. Chociaż te testy mogą pomóc Ci znaleźć błędy, są one droższe i zapewniają bardzo powolną informację zwrotną. Ponadto, w zależności od używanego narzędzia, stają się one bardzo kruche i ostatecznie spędzasz więcej czasu na utrzymaniu tych testów niż na pisaniu rzeczywistego kodu produkcyjnego. Warstwa usług w środku zawiera testy integracyjne, które nie wymagają interfejsu użytkownika. Na przykład w Railsach można bezpośrednio przetestować interfejs REST zamiast interakcji z elementami DOM.

Teraz wracam do pytania. Dowiedziałem się, że mogę znacznie zmniejszyć liczbę błędów w moim projekcie, który jest aplikacją internetową napisaną w Spring Roo (Java) z mnóstwem kodu JavaScript, wystarczy napisać wystarczającą liczbę testów jednostkowych dla JS. W moim zgłoszeniu jest dużo logiki napisanej w JS i to jest to, co testuję tutaj. Nie przejmuję się tym, jak strona będzie wyglądać lub czy animacje są odtwarzane tak, jak powinny. Testuję, czy moduły, które zapisuję w JS, wykonają oczekiwaną logikę, czy klasy elementów są poprawnie przypisane i czy warunki błędu są dobrze obsługiwane. Do tych testów używam Jasmine. To wspaniałe narzędzie. Jest bardzo łatwy do nauczenia i ma fajne szydercze zdolności, które nazywane są szpiegami. Jasmine-jQuery dodaje więcej doskonałej funkcjonalności, jeśli używasz jQuery. W szczególności pozwala określić urządzenia, które są fragmentami kodu HTML, dzięki czemu nie trzeba ręcznie kpić z DOM. Zintegrowaliśmy to narzędzie z mavenem, a testy te są częścią mojej strategii CI.

Musisz być ostrożny przy testach interfejsu użytkownika, szczególnie jeśli polegasz na narzędziach do nagrywania/odtwarzania, takich jak Selenium. Ponieważ interfejs użytkownika często się zmienia, testy te wciąż pękają, a ty poświęcasz dużo czasu na sprawdzenie, czy testy naprawdę się nie powiodły lub są po prostu nieaktualne. Ponadto nie dodają one tyle wartości, co testy jednostkowe. Ponieważ potrzebują one zintegrowanego środowiska do działania, najczęściej będziesz je uruchamiał dopiero po zakończeniu projektowania, gdy koszt naprawy będzie wyższy.

Dla testów dymu/regresji testy UI są jednak bardzo użyteczne. Jeśli chcesz je zautomatyzować, powinieneś uważać na pewne niebezpieczeństwa. Napisz swoje testy, nie nagrywaj ich. Nagrane testy zazwyczaj polegają na automatycznie generowanych ścieżkach x, które łamią się przy każdej niewielkiej zmianie w kodzie. Wierzę, że Cucumber to dobre ramy do pisania tych testów i można go używać wraz z WebDriver do automatyzacji interakcji przeglądarki. Kod myślenia o testach. W testach UI będziesz musiał łatwiej wyszukiwać elementy, więc nie musisz polegać na złożonych ścieżkach xpath. Dodanie elementów klasy i identyfikatora tam, gdzie zwykle nie byłoby to częste. Nie pisz testów dla każdego małego rogu. Te testy są kosztowne w pisaniu i trwają zbyt długo. Powinieneś skupić się na przypadkach, które eksplorują większość twoich funkcji. Jeśli napiszesz zbyt wiele testów na tym poziomie, prawdopodobnie przetestujesz tę samą funkcjonalność, którą wcześniej testowałeś na swoich testach jednostkowych (przypuść, że je napisałeś).

W moim bieżącym projekcie używam Spocka i Geb do napisania testów interfejsu użytkownika. Uważam te narzędzia za niesamowite. Są napisane w Groovy, co lepiej pasuje do mojego projektu Java.

Answer 3

Mimo że ten post dostaje wiele sympatii, chciałbym opublikować moją odpowiedź na moje pytanie, ponieważ piszę teraz wiele testów, a sposób testowania front-endu jest teraz bardzo długi.

Więc jeśli chodzi o testowanie FE spędziłem dużo czasu używając karma z Jasmine, chociaż karma będzie dobrze współpracować z innymi pakietami testowymi, takimi jak mocha & qunit. Chociaż są świetne, a karma pozwala na bezpośredni interfejs z przeglądarkami, aby uruchomić testy. Minusem jest to, że twój zestaw testów staje się duży, może stać się dość powolny.

Niedawno przeniosłem się do , która jest znacznie szybsza i jeśli twoja aplikacja do pisania reaguje, używając enzyme z testami snap-shot, daje naprawdę dobry zasięg. Mówienie o zasięgu Jest wbudowane i skonfigurowane w Stambule, a kpiny są naprawdę łatwe w użyciu. Wadą tego nie testuje w przeglądarce i używa czegoś, co nazywa się jsdom, co jest szybkie, ale ma kilka uciążliwości. Osobiście nie uważam, że jest to szczególnie ważne, gdy kompiluję mój kod za pomocą pakietu internetowego/babel, co oznacza, że ​​błędy w przeglądarkach krzyżowych są dość nieliczne, więc generalnie nie jest to problemem, jeśli ręcznie testujesz mimo wszystko (i imo powinieneś).

Pod względem pracy w stosie szyn, teraz jest tak łatwo, że klejnot sieciowy jest już dostępny i użycie npm i węzła jest generalnie znacznie bardziej wyjątkowe. Polecam używać nvm do zarządzania wersjami węzłów

Chociaż nie jest to ścisłe testowanie, polecam również używanie lintingu, ponieważ powoduje to również wiele problemów w kodzie. Dla JS Używam eslint z prettier i SCSS/css używam stylelint

Jeśli chodzi o co testować, myślę jak Carlos opowiada o piramidy testowym jest nadal aktualna, mimo wszystko teoria się nie zmienia, tylko narzędzia . Dodałbym także, że praktyczne są testy, zawsze testowałem, ale do jakiego poziomu i zasięgu będzie zależał projekt. Ważne jest, aby zarządzać czasem i spędzać godziny/dni na testowaniu krótkiego projektu cyklu życia.Większe/dłuższe projekty korzyści z większego zestawu testów są oczywiście większe.

W każdym razie mam nadzieję, że pomaga to ludziom, którzy patrzą na to pytanie.