Zabieram się właśnie za pisanie automatycznych testów do Repo. Automatyczny test (albo test jednostkowy) to kawałek kodu który sprawdza, czy inny kawałek kodu działa poprawnie. Czyli próbuje go używać na różne sposoby i alarmuje jeśli wydarzy się coś nieprzewidzianego. W Javie używa się biblioteki JUnit wspomagającej pisanie testów, dla .NET jest chyba coś podobnego. Pewnie istnieje też jakiś PyUnit. Miłe jest też to, że Eclipse bardzo pomaga w tworzeniu i korzystaniu z testów.

Nie znam się na automatycznych testach. I dlatego chcę dorobić trochę testów do Repo.

Zamiast testować struktury danych, zachowanie bazy etc. postanowiłem zacząć od testowania tego, co widać w przeglądarce. To bardziej nietypowe - wszystkie testy jakie gdzieś widziałem operują na poziomie kodu, wywołują metody i sprawdzają wartości przez nie zwracane, etc. Repo również powinno mieć takie testy (np. tworzące nowy obiekt w bazie danych, sprawdzające czy ma poprawną zawartość, usuwanie go, sprawdzanie czy zniknął, tworzenie niepoprawnego obiektu, sprawdzanie czy zostało to wyłapane itp.), ale nimi zajmę się później.

Na razie interesuje mnie podejście bardziej "zewnętrzne", takie, które testuje Repo poprzez serwer http. Zacząłem więc szukać sobie gotowego toolkitu, i proszę - znalazłem HtmlUnit. Jejciu, jakie to fajniutkie :)

W odróżnieniu od innych "wspomagaczy" ten pozwala operować na dość wysokim poziomie (czyli bez babrania się w nagłówkach HTTP, choć można uzyskać dostęp i do tych danych).

W praktyce wygląda to tak, że tworzy się obiekt klienta i każe mu wejść na jakiś URL. Jako odpowiedź otrzymuje się obiekt strony. Można wyciągnąć z niego od razu takie rzeczy jak kodowanie, tytuł, treść (czysty tekst, przeformatowany na XML, albo surowy output serwera (dobry żeby pchnąć od razu na jakiś walidator)). Osobną metodą można dostać listę wszystkich "anchors" ze strony (czyli linków). "Anchors" mają m.in. metodę click(), która symuluje użycie linka i zwraca kolejną stronę. Można się dobierać do konkretnych elementów strony, wyciągać formularze, wypełniać pola, sprawdzać kodowania, nazwy linków, no po prostu dokładnie to, o co mi chodziło. Nawet Javascript jakoś interpretuje, więc click() pewnie zadziała na linkach wywołujących JS. Można ustawić sobie nazwę przeglądarki, własne nagłówki, wykonywać POST-y, są nawet gotowe metody do przeskakiwania tab-em po elementach strony, sprawdzania czy są podefiniowane access keys, no jednym słowem masa frajdy :)

Najpierw zrobię sobie test, który przelezie się po całym repo (skacząc z odnośnika na odnośnik) i posprawdza, czy strony są dostępne (czyli je wywoła i sprawdzi, czy kod wyjścia to java.net.HttpURLConnection.HTTP_OK). Do tego dołożę sprawdzanie XML-a (czy wszystko się waliduje należycie), potem może jakieś testy dodawania komentarzy (czy da się wysłać komentarz bez odpowiednio wypełnionych pól, czy są tworzone odpowiednie ciasteczka etc.). Ech... rajcuje mnie to. Lubię tak wygodne technologie, bo mają bardzo bezpośredni przelicznik między "mam pomysł jak zrobić coś fajowego" a implementowaniem tego. Nie lubię języków niskopoziomowych właśnie dlatego, że za dużo czasu mija między pomysłem a zobaczeniem go w akcji. W programowaniu interesuje mnie tworzenie czegoś własnego, wcielanie pomysłów w życie. To takie klocki lego dla dużych chłopców. Jeśli przyjdzie mi do głowy napisać test, który próbuje wysłać komentarz bez podania adresu e-mail i sprawdza, czy w odpowiedzi dostaje stronę z komunikatem o odpowiedniej treści, to w HtmlUnit zajmie to dosłownie parę wierszy. Bardzo lubię takie klocki :)

Od: maniel
Data: 20061123, 16:21
Hmm, <podstępnie> to nie Ty na linux@ zastanawiałeś się [żeby nie powiedzieć „wykłucałeś się”] po cholerę komu parser html [bo można w ff sprawdzić itp.]?:P:)

Btw, czy ja mam takie szczęście czy w całym repo masz jeden text antyspamowy? Mam na myśli "Żółty tulipan w wazonie.":P Bo już kolejny raz nań trafiłem:)

Od: bies
Data: 20061123, 23:50
HtmlUnit... Hmm, muszę w wolnej chwili (TM) przyjrzeć się temu. Chociaż mam wątpliwości czy poradzi sobie z wyjściem z SAP EP. Ale jeśli nawet zapewni testowanie pojedynczych pod-stron i tak będzie dobrze.

Od: void
Data: 20061124, 11:23
Ostatnio miałem okazję zacząć pracę w projekcie opartym na TDD (Test-Driven Development). Bardzo mi się spodobało to podejście, choć nie zawsze można je stosować. (BTW: Temat tamtego projektu był niczym z Tolkiena - "ELF & DWARF").

Ja lubię języki niskiego poziomu właśnie za to, że można usiąść i łatwo coś zaimplementować, bez problemów z przenośnością.
Wybór języka zależy, według mnie, mocno od poziomu na którym powinien on operować. Podejżewam, że dość trudno czyta się zawartość rejestrów procesora ARM w Javie.

Od: Aniołek
Data: 20061124, 15:49
Przenośność w językach niskiego poziomu? Czy my na pewno myślimy o tych samych językach niskiego poziomu? ;]

Od: void
Data: 20061125, 11:00
Ja myślę o C/C++ (koledzy do tego dodali ostatnio bibliotekę boost). Nie znam bardziej przenośnego języka niż C.
Wiem, że nie jest on typowo "językiem niskiego poziomu", ale użyłem tej nazwy w odniesieniu do wpisu Hoppke.

Od: bies
Data: 20061125, 20:55
C jest językiem niskiego poziomu. To przecież zaledwie asembler na sterydach. C++ natomiast to zupełnie inna sprawa. To jest chyba jedyny znany mi język wszelkiego poziomu. Można pisać jak w C a można pisać na ekstremalnie wysokim poziomie (deklaratywnie) - polecam Boost.Spirit lub Boost.MPL.

A, akurat na ARM powinno dać się zmieścić JVM (może ciut okrojoną, bez FPU, GC). Inna sprawa, że czytanie rejestrów procesora ma sens tylko w czytaniu rejestrów JVM. Do wyskoczenia poza wirtualną maszynę Java potrzebuje natywnego wsparcia.

Od: bies
Data: 20061125, 22:30
Aha
:powyżejs/asembler/makroasembler/

Od: Aniołek
Data: 20061127, 15:32
No jak ktoś programuje nie używając za bardzo bibliotek to C jest przenośne... Tyle że jakoś ciężko mi sobie wyobrazić cokolwiek większego bez używania bibliotek.

Od: void
Data: 20061128, 11:09
@Aniołek: Większość bibliotek C jest przenośna (np. libcurl), więc jeśli nie używasz GUI to masz dość spore możliwości.

Od: Aniołek
Data: 20061128, 12:15
To widać ja w jakichś dziwnych bibliotekach musiałam na studiach (na systemy operacyjne) pisać i mam zgoła odmienne zdanie co do tej "większości" ;) Ale kłócić mi się nie chce, bo to jak wiadomo zawsze zależy od zastosowań. Tak czy owak całkiem spora liczba aplikacji pisanych w C/C++ leżących na SF ma wymieniany jeden system jako współpracujący, więc... no szczerze - dla mnie średnia to "super przenośność", jeśli musisz się nagimnastykować i tylko wybranych bibliotek możesz używać.
Nie twierdzę że C/C++ są absolutnie nieprzenośne, natomiast twierdzenie że ich zaletą (względem np. javy) jest przenośność brzmi jednak dla mnie dość zabawnie.

Od: void
Data: 20061129, 11:03
Nasze spojrzenie na tą sprawę różni się pewnie dlatego, że ja piszę oprogramowanie wspierające produkcję urządzań, które działa najczęściej bez monitora, a Ty pewnie oprogramowanie z typowym front-endem GUI.
Mnie już wiele lat temu Java+swig zraziła swoją ociężałością, więc jestem trochę uprzedzony, ale rozumiem Twoje stanowisko i czasami widzę rozwiązanie, gdzie java się sprawdza.

Od: Aniołek
Data: 20061202, 11:42
Wiesz co void? Chyba Cię trochę nie rozumiem. Piszesz i zdajesz sobie sprawę z tego, że Twoje zastosowanie i soft który piszesz do popularnych nie należy.
Jakby tak procentowo popatrzeć na to, co robi się w firmach, to z całą pewnością nikła część programistów ma do czynienia z systemami, które być może nawet nie mają monitora.
Mało tego, stosunkowo mała część powstającego teraz softu to soft "pudełkowany", coraz częściej są to produkty pod klucz, dla konkretnego klienta, na dodatek powstające w formie aplikacji webowych a nie desktopowych (gdzie rzeczywiście swing, a nawet SWT, są stosunkowo ciężkie).
W tej większości zastosowań absolutny prym wiodą Java i .NET. C/C++, jak sam zauważasz, jest stosowane w przypadkach NIETYPOWYCH. Więc po co się spierasz o jego wyższość?
Owszem, są obszary gdzie C/C++ jest znacznie lepsze niż Java/.NET, są obszary gdzie zdecydowanie lepszy będzie nawet assembler oraz obszary gdzie lepiej sprawdzi się AWK, Python, Ruby, Lisp albo cholera wie co jeszcze.
Tyle że jeśli chcemy generalizować i spierać się na poziomie "globalnym" to niestety globalnie najczęściej poszukuje się programistów Javy (enterprise, łącznie z wszystkimi technologiami powiązanymi) i .NETa - i to te obszary dają ludziom najwięcej pracy.
Nikt tu jednak nigdy nie twierdził że nie ma miejsc, gdzie inne języki sprawdzają się lepiej - tyle że takich miejsc jest mniejszość. A Ty na podstawie tej mniejszości starasz się udowodnić że... no właściwie właśnie nie wiem co. Że C/C++ wcale nie ustępuje Javie, a nawet jest lepszy? Wszystko zależy od rozpatrywanego obszaru zastosowań... Twój punkt widzenia raczej ciężko podzielić większości ludzi, którzy zajmują się programowaniem zawodowo, bo (statystycznie rzecz biorąc) oni dłubią właśnie w systemach webowych w Javie albo .NET.