Co należy przetestować w Javascript?

W pracy właśnie uruchomiliśmy aplikację opartą w dużej mierze na Javascripcie (faktycznie używającą Coffeescript, ale nadal), której wdrażam zautomatyzowany system testowy z wykorzystaniem JsTestDriver i tkaniny.

Nigdy nie napisaliśmy czegoś z tak dużą ilością Javascript, więc do tej pory nigdy nie przeprowadzaliśmy testów Javascript. Nie jestem pewien, co dokładnie powinniśmy testować w naszych testach jednostkowych. Napisaliśmy wtyczki JQuery do różnych rzeczy, więc jest całkiem oczywiste, że należy je zweryfikować pod kątem poprawności w jak największym stopniu za pomocą JsTestDriver, ale wszyscy inni w moim zespole wydają się myśleć, że powinniśmy również testować JavaScript na poziomie strony.

Nie sądzę, że powinniśmy testować Javascript na poziomie strony jako testy jednostkowe, ale zamiast tego używamy systemu takiego jak Selenium do sprawdzania, czy wszystko działa zgodnie z oczekiwaniami. Moim głównym uzasadnieniem jest to, że w tej chwili testy JavaScript na poziomie strony nie mogą przejść przez JsTestDriver, ponieważ próbują uzyskać dostęp do elementów w DOM, które prawdopodobnie nie mogą istnieć.

Więc co powinno być testowane jednostkowo w JavaScript?

javascript testing unit-testing

— Nathan Hoad
źródło

Izolujesz każdy kod javascript, który napisałeś w modułach. Następnie po prostu testujesz wejścia i wyjścia tych modułów. Każdy moduł, który obsługuje DOM, oznacza, że musisz przetestować DOM. Użyj lepszego narzędzia niż jsTestDriver.

— Raynos,

Powinieneś być jednostką testującą logikę biznesową. Jeśli logika biznesowa i elementy w DOM są ze sobą powiązane, masz wadę projektową. Wyodrębnij jak najwięcej logiki biznesowej z elementów strony, aby można ją było odpowiednio przetestować jednostkowo. Do weryfikacji interakcji elementu DOM powinieneś używać Selenium.

— wałek klonowy

@NathanHoad Piszecie testy jednostkowe uruchamiane w samej przeglądarce, sensowne są narzędzia nodeunit, qunit i jaśmin. Podczas pracy w przeglądarce masz DOM. Możesz użyć narzędzia takiego jak testling, aby zautomatyzować testowanie w przeglądarce.

— Raynos

Dzięki. Patrzyłem w kierunku jsTestDriver, ponieważ twierdziło, że jest w stanie działać w przeglądarce, co, choć technicznie prawdziwe, odkryłem, że nie jest tym samym, co uruchamianie z QUnit. Pracuję nad własnym narzędziem, które korzysta z QUnit, z niestandardowym panelem paska narzędzi do debugowania Django. Za pomocą Selenium będę w stanie wykryć testy zakończone niepowodzeniem. Poza tym wątpię, by mój szef zapłacił za testling, choć wygląda całkiem nieźle!

— Nathan Hoad,

powiązane: W jaki sposób przeprowadzasz test javascript

— gnat

Odpowiedzi:

Przetestuj wszystko, co możesz.

Czysta logika może być łatwo przetestowana.

Jeśli Twój kod współdziała z DOM lub siecią, jest to o wiele trudniejsze.

Jeśli potrafisz wyodrębnić fragment kodu, który będzie działał na dowolnym elemencie DOM zamiast na konkretnym, możesz go łatwiej przetestować. (Spraw, aby element działał na parametrze).

Kod korzystający z Ajax można przetestować, po prostu wywołując funkcję zwrotną ze stałymi danymi. Miałem kilka testów, w których nadpisałem $.ajaxwłasną funkcją. Po prostu upewnij się, że odłożysz prawdziwy, gdy skończysz!

Przekonasz się, że „javascript na poziomie strony” naprawdę oznacza „ściśle powiązany kod”, a jeśli oddzielisz części kodu, możesz je przetestować niezależnie.

(Selenium nie jest narzędziem do testowania jednostek. Świetnie sprawdza się w scenariuszach wysokiego poziomu, ale nie można go testować i nie działa w odizolowanym środowisku).

— Sean McMillan
źródło

jaśmin może kpić z wywołań funkcji i danych odpowiedzi, możesz przyjrzeć się temu zamiast nadpisywać funkcje.

— Steve,

Powinienem wyjaśnić - na każdej stronie mamy takie funkcje. Mówiłem więcej o testowaniu kodu, który wykonuje się w środku $(document).ready(...).

— Nathan Hoad

Wszystko ...zależy od tego, jak duże to jest. :-) Czuję, że powinieneś być w stanie sprowadzić to do pojedynczej nazwanej funkcji, która jest również testowana. Wówczas twój nieprzetestowany kod jest jednym wierszem. (Teraz to jest cel, a nie dany. W praktyce zawsze miałem więcej niż jedną linię nieprzetestowanego kodu.)

— Sean McMillan

@SeanMcMillan - Bardzo trudno mi przetestować części aplikacji, które wpływają tylko na DOM, na przykład funkcję, która wiąże tylko kilka zdarzeń z niektórymi elementami DOM. Jak sprawdzisz, czy te zdarzenia zostały poprawnie zapisane? nie jest to coś, co mogą zrobić testy jednostkowe, ale prawdziwe klikanie i sprawdzanie w przeglądarce (za pomocą selenu lub cokolwiek innego)

— vsync

@vsync: Można dość łatwo przetestować, powiedzmy, moduł obsługi kliknięć do danego elementu DOM. Nie sądzę, aby można było przetestować, czy „kliknięcie” jest właściwym modułem obsługi i czy przypisałeś je do odpowiedniego elementu.

— Sean McMillan,

Algorytmy testowe. Części ściśle związane z GUI są bardziej zależne od konkretnej przeglądarki, dlatego należy je przetestować za pomocą narzędzi podobnych do selenu.

Twój kod musi oczywiście zawierać algorytmy jako izolowane fragmenty kodu, jeśli nie, testowanie jednostkowe jest prawie niemożliwe.

wtyczki jquery, btw, nie są łatwe do testowania jednostkowego.

— Sergey Stolyarov
źródło

Wszystkie dobre punkty! Zgadzam się, że nie są one również łatwe do testowania jednostkowego, w zależności od tego, jak zostały napisane.

— Nathan Hoad

-1

Kiedyś pracowałem z Javą iz tego, co widzę, testowanie jednostkowe Java jest łatwiejsze niż testowanie jednostkowe JavaScript, ponieważ Java jest bardziej sztywna.

Jestem sprzedawany na podstawie tego, że rozwój oparty na testach jest najlepszą rzeczą, więc badam również, jak testować jednostkowo JavaScript. W Javie wyśmiewałem kod, który nawiązał połączenie z bazą danych, obiekty dostępu do danych i porównuję go z kodem w JavaScript, który zmienia DOM i kodem, który wywołuje wywołania AJAX do serwera.

Chodzi mi o to, że wydaje mi się, że to, co należy przetestować, to logika wprost. Na przykład nie chcesz wykonywać wywołania AJAX podczas uruchamiania testów jednostkowych, ponieważ (a) potrzebujesz, aby serwer działał i (b) działa wolno, a jedną z wytycznych dotyczących testów jednostkowych jest to, że musi być super szybko, aby programiści nie unikali uruchamiania ich jak co minutę.

Inną wskazówką jest, aby proces ciągłej integracji wysłał wiadomość e-mail z informacją, że nie udało się przeprowadzić testu jednostkowego.

— SBel
źródło