Pisanie testów w JavaScript

JavaScript potrafi być upierdliwe ;).
Pomijając problem z manipulacja DOM, ciężko się tworzy w tym kod, który możesz od razu sprawdzić czy debgować. Teraz trochę się to zmieniło, porównując to do czasów kiedy zaczynałem się poważniej zajmować JavaScriptem: przykładowo mamy FireBug_a i inne dodatki do przeglądarek, które ułatwiają nam zrozumienie co się dzieje w kodzie.
Jednak problemy typu: brak średnika lub sama literówka w nazwie zmiennej są najczęściej odkrywane w przeglądarce kiedy uruchamiamy daną stronę i widzimy że wyrzucane są wyjątki. Taki błędy odkrywane są powoli.

Rozwiązanie tych problemów może być pisanie testów. Wymaga to jednak pewnego zachodu np. porządku w plikach js, tak aby nie ciągnąć za sobą zbyt dużo zależności. Do końca sam nie wiem jak się do tego dobrze zabrać.
Sposób jaki postaram się tu przedstawić jest dobry do testowania prostych koncepcji lub nauki JavaScriptu.

Wszystko zaczyna się od narzędzia jakim jest js-test-driver. Pod podanym linkiem jest strona tego narzędzia, a na niej filmik prezentujący sposób pracy z nim (polecam go obejrzeć, to co opiszę dalej w dużym stopniu opera się o to co zostało tam pokazane). Używanie tego wymaga pewnego zachodu z ustawieniem środowiska pracy, tak aby testować kod we wskazanych przeglądarkach.

Tutaj jest dobre miejsce do startu, są tu przykładowe testy wraz ze wszystkim co jest potrzebne do uruchomienia, Potrzebne pliki (jary) można jednak pobrać z innego miejsca. Także idąc za podanym przykładem, testy będę pisał w oparciu o ten sam problem „gra w życie” (szczegóły).

Jak uruchomić serwer testów
A więc zaczynajmy od uruchomienia serwera, należy mieć odpowiedni jar (tutaj jest to JsTestDriver-1.3.5.jar). Serwer można uruchomić poniższą komendą:

java -jar JsTestDriver-1.3.5.jar --port 9876

Lub za pomocą skryptu, zawierającą tą komendę. Jest to najprostsza konfiguracja gdzie jedynym istotnym parametrem jest port pod którym będzie dostępny serwer. Po wystartowaniu serwera należy otworzyć przeglądarkę, w której chce się testować (można testować jednocześnie pod kilkoma), i podać adres:

http://localhost:9876

Następnie kliknąć link „Capture This Browser” i przeglądarka jest przechwycona do testów.

Jak uruchomić testy
Testy uruchamia się podobną komendą, choć jest ona trochę bardziej skomplikowana. U mnie upchnięta do pliku bat wygląda tak:

set BASE_DIR=D:\game-of-life
java -jar "%BASE_DIR%\JsTestDriver-1.3.5.jar" ^
--config "%BASE_DIR%\jsTestDriver.conf" ^
--basePath "%BASE_DIR%" ^
--tests all --reset

W podanym przykładzie wszystkie pliki są w tym samym katalogu. Plik jsTestDriver.conf z konfiguracją mówiący o tym co ma być wczytane podczas uruchamiania testów i pod jakim adresem działa serwer testów. Wygląda on tak:

server: http://localhost:9876

load:
- js/jasmine.js
- js/JasmineAdapter.js
- http://underscorejs.org/underscore-min.js
- game-of-life.js
- game-of-life-tests.js


Kończąc ten opis jak uruchomić testy.
Całość kodu jest dostępna tutaj. A sama symulacja życia może być podziwiana tutaj. Fajny sposób do dzielenia się kawałkami kodu ;). Można na żywo edytować i sprawdzać jak zmiany się zachowują. Polecam pobawić się zmianą reguł życia.

O testowaniu

Ostatnio doświadczyłem jak pożytecznym narzędziem potrafią być testy. Chodzi o przypadek, w którym pomagają one skrócić czas, jaki jest pomiędzy zrodzenia się pomysłu, a wdrożeniem go i sprawdzenia czy jest dobry.

Refleksja o/w testach

Używanie refleksji w normalnym/produkcyjnym kodzie może wydawać się: dziwne, wprowadzające komplikacje, czy zbyt duże obciążenie (zamieszanie), niekoszerne … Warto jednak zapoznać się z paroma sztuczkami, aby ułatwić sobie czasami testowanie.

Dzięki refleksji można zbudować proste narzędzia przydatne przy:
– wstrzykiwaniu zależności (ustawianie wartości), kiedy w normalny sposób nie można tego zrobić;
– pobieraniu wartości (tak samo jak wyżej, kiedy nie ma mechanizmu do tego).
Można powiedzieć, że zawsze da się sprawić, żeby to co nie jest dostępne było dostępne. Jednak jeśli jest to robione tylko na potrzeby testu, to może się wydawać zbyteczne (kod służący tylko do testowania jest w kodzie produkcyjnym, coś jak). Tu argumentem za jest także przypadek gdy pracujemy na kodzie, którego po prostu nie możemy zmienić.

Dlatego mechanizm operujący na obiektach danej klasy, a nie kod wewnątrz tej klasy, może być użyteczny.
W podstawowej wersji może sprowadzać się to do dwóch metod (szczegóły tego jak to zostało zaimplementowane tutaj):

	public static void setFiledValue(Object target, String filedNmae, Object value){
		...
	}
	
	public static Object getFiledValue(Object target, String filedNmae){
		...
	}

Gdzie to można użyć?
Wstrzykiwania zależności, np. do testowania EJB, gdzie mam wiele pól, które mają być ustawione przez kontener. Oczywiście można zawsze dostarczyć to bez takiego mechanizmu – użycie setterów lub stworzenie odpowiednich konstruktorów ;).

Pobieranie wartości, których normalnie nie da się pobrać. To jest przydatne w weryfikacji: czy to co miało się wykonać, wykonało się poprawnie i czy odpowiedni stan został ustawiony.
W ostatnim przypadku, także pewnie można znaleźć zamiennik.

Zawsze można powiedzieć, że gdzieś tam jest wspaniała biblioteka lub technika tworzenia kodu, która uwolni nas od takich problemów. Niemniej świadomość, że można tak robić, może być kolejnym sposobem na ugryzienie problemu lub przynajmniej wskazania rozwiązania dla niego ;).