My tests href="http://github.com/jquery/qunit/raw/master/qunit/qunit.css " type="text/css" media="screen"> href="http://code.jquery.com/qunit/qunit-git.css" />
Poleć ksi k Kup ksi k Rozdział 5. Przetestowany kod 91
Example QUnit Test/h1>
Plik myapp.js zawiera kod, który chcesz przetestować. Natomiast w pliku tests.js zawarty jest zestaw testów jednostkowych QUnit. Pamiętaj, aby odnośniki do plików z testami zostały umieszczone dopiero po kodzie, który masz zamiar testować. Wewnątrz znacznika body trzymane są elementy, w których będą reprezentowane wyniki testów. Asercje Podstawowym narzędziem, jakim posługujemy się, pisząc testy jed- nostkowe, są asercje. Być może zetknąłeś się już z tym pojęciem pod- czas pracy z innymi językami programowania. Asercje służą do sprawdzania, czy wartość zwrócona przez kod programu jest zgodna z oczekiwaniami. Pozwala to na automatyczne wykrywanie błędów i szybkie znalezienie błędnie działającego kodu. W bibliotece QUnit najprostsza z asercji jest realizowana przez funk- cję ok(). Wykonuje ona sprawdzenie, czy podany argument jest prawdziwy. Przyjrzyjmy się przykładowemu testowi: test( "Simple example", function() { var value = 10 > 5; ok( value, "We expect 10 to be greater than 5" ); }); Najpierw wywołujemy metodę test(), która konstruuje test jednost- kowy. Pierwszym jej parametrem jest nazwa sprawdzanej funkcjonal- ności, zobaczysz ją potem w wynikach zestawu testów. Jako drugi parametr przyjmowana jest funkcja, w której będziesz implemen- tować testy. W tym prostym przypadku przypisujemy do zmiennej value wartość wyrażenia 10 > 5 (czyli true). Następnie wykonywana Poleć ksi k Kup ksi k 92 jQuery. Kod doskonały jest asercja ok(value). Jeśli wartość value jest prawdziwa, wówczas test zakończony zostaje sukcesem. Po umieszczeniu powyższego kodu w pliku tests.js i uruchomieniu w przeglądarce strony z listingu 5.1 zobaczymy wynik uruchomienia testów pokazany na rysunku 5.1. Rysunek 5.1. Rezultat wykonania prostego testu w QUnit W rezultacie na stronie widzimy między innymi nazwę naszego ze- stawu testów, wersję przeglądarki, w której zostały one uruchomio- ne, oraz wyniki poszczególnych testów jednostkowych. Dodajmy do naszego zestawu jeszcze jedną asercję, która tym razem nie za- kończy się sukcesem: test( "Simple example 2", function () { var value1 = true || false, value2 = false; ok( value1, "We expect boolean operators are working fine"); ok( value2, "This test will not pass"); }); Rezultaty testów można zobaczyć na rysunku 5.2. Rysunek 5.2. Testy, które zakończyły się niepowodzeniem, są odpowiednio oznaczone Poleć ksi k Kup ksi k Rozdział 5. Przetestowany kod 93 Testy, które nie zakończyły się sukcesem, oznaczone są czerwonym kolorem. Ponadto wskazana jest konkretna asercja, która zwróciła błąd wraz z odpowiadającym jej numerem linii kodu. W takim wy- padku otrzymujesz natychmiast informację zwrotną, która pozwoli Ci na poprawienie działania aplikacji (lub poprawienie testów). Porównania Funkcja ok() daje jedynie możliwość sprawdzenia, czy określona wartość jest prawdziwa. Jeżeli za jej pomocą zechcesz porównywać wartości, należałoby przekazać do niej rezultat porównania jako pierwszy argument funkcji: test( "Equality test", function () { ok( 5 * 5 == 25, "We expect multiplication works fine"); }); Funkcja ok() jest tylko jedną z dostępnych asercji. Jeżeli interesuje Cię wynik porównania dwóch wartości, posłuż się funkcją equal(). Przyjmuje ona trzy argumenty. Argument pierwszy porównywany jest z drugim i jeśli nie zachodzi między nimi równość, wówczas zwracany jest błąd. Trzecim argumentem jest słowny opis asercji. Test z użyciem equal() może przybrać następującą postać: test( "Equality test", function () { equal( 5 * 5, 25, "We expect multiplication works fine"); }); Ten test zakończy się sukcesem. Możesz również zechcieć upewnić się, że dane obiekty nie są sobie równe. W takim wypadku posłuż się asercją notEqual(): test( "Equality test", function() { notEqual( 1 , 2, "We expect 1 does not equal 2"); }); Ten test również zakończy się sukcesem, ponieważ 1 != 2. Zwróć uwagę, że cały czas mówimy o sprawdzaniu relacji równości, a nie identyczności. Na przykład następujące asercje: equal( "25", 25); equal( 1, true); Poleć ksi k Kup ksi k 94 jQuery. Kod doskonały będą prawdziwe i nie zwrócą błędu. Odpowiada to użyciu operatora == zamiast ===. Jeżeli porównując obiekty, chcesz uniknąć niejednoznacz- ności i sprawdzać przy tym ich typy, posłuż się asercją strictEqual(). Używana jest ona dokładnie w ten sam sposób co equal(): test( "Strict equality test", function () { strictEqual( 1, 1); strictEqual( "25", 25); strictEqual( 1, true); }); Wyniki powyższego testu pokazane są na rysunku 5.3. Rysunek 5.3. Użycie asercji strictEqual() odpowiada posłużeniu się operatorem === Dostępna jest również asercja notStrictEqual(), która działa analo- gicznie jak notEqual(). Na przykład następujące asercje zakończą się sukcesem: notStrictEqual( "25", 25); notStrictEqual( 1, true); Do Ciebie należy decyzja, której z asercji powinieneś użyć. Możesz również po prostu używać funkcji ok(), która za argument będzie przyjmować wynik porównania obiektów. Jak dotąd dokonywaliśmy asercji jedynie z użyciem prostych obiek- tów. Aby móc porównywać złożone obiekty, posłuż się metodą deepEqual() (lub odpowiednio metodą notDeepEqual()): Poleć ksi k Kup ksi k Rozdział 5. Przetestowany kod 95 test( "Deep equal test", function () { var foo = { baz: 1 } equal( foo, { baz: 1}, "equal assertion will fail") deepEqual( foo, { baz: 1}, "deepEqual assertion will be success") }); Wyniki testu pokazane są na rysunku 5.4. Rysunek 5.4. W przypadku porównywania złożonych obiektów posłuż się asercją deepEqual() Jak widać, użycie asercji equal() zakończyło się niepowodzeniem. Metody equal() oraz strictEqual() nie nadają się do porównywa- nia złożonych obiektów. W ich przypadku asercja zwróci błąd. Struktura testów Pisanie testów jeden po drugim w sposób liniowy może utrudnić orientację w kodzie. Podobnie jeśli zawrzesz wszystkie asercje w jed- nym teście wtedy testy staną się nieczytelne i trudne w utrzymaniu. Dobrze by było, abyś podzielił pliki z testami na takie, które odno- szą się do osobnych funkcjonalności kodu JavaScript. Ponadto każdy z testów powinien dotyczyć oddzielnej składowej testowanej funk- cjonalności. Aby wyniki testów były bardziej czytelne i utrzymane w pewnym porządku, QUnit udostępnia funkcję module(). Pozwala ona na grupowanie testów ze względu na funkcjonalność, jaką obejmują. Poleć ksi k Kup ksi k 96 jQuery. Kod doskonały Jako argument przyjmuje ona nazwę aktualnie testowanego mo- dułu. Spójrzmy na poniższy przykład: module("Module A test"); test( "Basic test", function () { ok(1); }); test( "Basic test 2", function () { ok(true); }); module("Module B test"); test( "Another test", function () { equal( 5, "5"); }); W takim wypadku testy są podzielone na dwie grupy. Dwa pierwsze testy należą do pierwszego modułu, a trzeci test do drugiego. Pozwoli Ci to na łatwiejsze utrzymywanie porządku w kodzie. Ponadto przy każdym z wyników testu będzie dodatkowo napisane, jakiego mo- dułu on dotyczy. Testy asynchroniczne Dotychczas opisywane testy wykonywane były w sposób synchronicz- ny. Oznacza to, że każdy kolejny test uruchamiany jest dopiero wtedy, kiedy ostatni test zostanie zakończony. W takim wypadku testowanie funkcji asynchronicznych takich jak $.ajax() lub setTimeout() za- kończy się niepowodzeniem. Spójrzmy na poniższy przykład: test("Asynchronous test", function () { setTimeout( function () { ok(true); }, 1000 ); }); Po uruchomieniu takiego testu otrzymujemy w rezultacie następu- jącą informację: 0 tests of 1 passed, 1 failed. ... Expected at least one assertion, but none were run - call expect(0) to accept zero assertions. Poleć ksi k Kup ksi k Rozdział 5. Przetestowany kod 97 Oznacza to, że asercja ok(true) nie została w ogóle uruchomiona, ponieważ test został ukończony, zanim doszło do jej wykonania. Aby wykonać testy w sposób asynchroniczny, musisz posłużyć się funk- cjami stop() i start(). Odpowiadają one za wstrzymywanie i wzna- wianie procesu wykonywania testów. Omawiany test powinien przybrać następującą postać: test("Asynchronous test", function () { setTimeout( function () { ok(true); start(); }, 1000 ); stop(); }); Kiedy test dobiega końca, uruchomiona zostaje funkcja stop() i testy przechodzą w etap wstrzymania. Kolejne testy nie zostaną urucho- mione, dopóki nie zostanie wywołana funkcja start(). Umożliwi to wykonanie asercji ok(), która uruchomiona zostanie dopiero po upływie sekundy. Po wykonaniu asercji następuje wykonanie funk- cji start(), co przywraca normalny bieg testów. Przypomina to nieco rozwiązanie problemu synchronizacji z użyciem semaforów. Dostępny jest również test asyncTest(), który domyślnie wywołuje stop() na końcu testu. Dzięki temu możemy stosować nieco prostszy zapis: asyncTest("Asynchronous test", function () { setTimeout( function () { ok(true); start(); }, 1000 ); }); Podobną postać przybierze wysłanie żądania AJAX do serwera: asyncTest("Asynchronous test", function () { $.ajax({ url: "http://localhost/", success: function (data) { ok(true); start(); } }); }); Poleć ksi k Kup ksi k 98 jQuery. Kod doskonały Możesz również zrezygnować z rozwiązywania tego problemu, tworząc synchroniczne żądania AJAX. W tym celu ustaw wartość pola async na false. test("Asynchronous test", function () { $.ajax({ url: "http://localhost/", async: false, success: function (data) { ok(true); } }); }); Możesz również przed uruchomieniem zestawu testów ustawić syn- chroniczne żądania AJAX jako domyślne: jQuery.ajaxSetup({async:false}); W takim wypadku możesz zaniedbać problem synchronizacji. Przykładowy zestaw testów Zajmijmy się teraz nieco bardziej realistycznym przypadkiem. Utwo- rzymy prostą wtyczkę wraz z zestawem testów. Wtyczka będzie im- plementować uproszczoną obsługę zakładek na stronie. Przykładowa struktura kodu HTML, na którym będzie uruchomiony plugin, będzie wyglądać tak jak na listingu 5.2. Listing 5.2. Kod HTML, którym posługiwać się będzie wtyczka