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?
źródło
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).
źródło
$(document).ready(...)....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.)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.
źródło
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.
źródło