Witam,

Od dłuższego czasu drąże temat Test Driven Development, powoli w oparciu o nowe narzędzia wdrażam z ciekawymi konsekwencjami metodologie opartą o testy.

Na bazie właśnie realizowanego projektu postanowiłem podzielić się swoimi spostrzeżeniami:
1. Dobra architektura aplikacji umożliwiająca testy jednostkowe to podstawa (dobry podział na model/akcje i BO).
2. Faktyczne pisanie testów zanim powstanie choćby jeden mm kodu - tzn. po stworzeniu dokumentacji funkcjonalnej (specyfikacji wymagań) piszemy pierwsze testy jednostkowe.
3. Zauroczyłem się w metodologii continues integration - praca tylko i wyłącznie w oparciu o system wersjonowania (cvs/svn) do tego pełna automatyzacja budowy aplikacji (ant, ew. phing) + testy - i to w całości codziennie, najlepiej co kilka minut.
4. Oszczędność czasu w późniejszyme etapie - dopóki nie napisze się pierwszej poważnej aplikacji w oparciu o TDD nie sposób zauważyć jej zalety, a są one nie wiarygodne, a szczególnie oszczędność czasu poświęcana na testowanie aplikacji przy wprowadzaniu zmian itp.

Dobra a teraz krótko, jak działamy:
- dla każdej metody piszemy test - im test dokładniejszy i ściślejszy tym lepiej,
- wersjonujemy aplikację,
- automatyzujemy proces instalacji aplikacji (ant, ew. phing),
- codzienne buildy,
- wykorzystujemy narzędzia wspierające proces testowania i automatycznego budowania aplikacji.

Z czego ja korzystam?
- continuum - automatyzacja całego procesu, raporty etc,
- cvs - wersjonowanie,
- PHPUnit 2, selenium - testy,

Dodatkowo ciekawe linki wprowadzające:
TDD
Ciekawe podejście
phpunit w wersji 3 w drodze

Pytania, moje
1. Z jakich narzędzi wy korzystacie wspierających waszą pracę na etapie testów, wdrożenia?
2. Znacie jakieś dobre narzędzie testujące funkcjonalnie GUI, symulujące użytkownika? Tzn, wypełnia sobie formularz, sprawdza poprawnosc zwracanych danych, mierzy czas generowania kolejnego ekranu itd - oczywiście wszystko ja definiuje w postaci testu (dane ktore ma wrzucic do forma, pola w formie itp).
3. Automatyzacja instalacji, w php znalazłem tylko phinga, póki co korzystam z Anta (tak jak w jednym z linków jest wspomniane - dobrze integruje się z pewnymi narzędziami),ale interesuje mnie pełna automatyzacja tego procesu - defacto pełne paczki (coś na kształt plików .war) samoinstalujące się

Chętnie poczytam wasze spostrzeżenia.

Pozdrawiam,
Patrycjusz Szydło

Witam.
patrycjusz widze, że rozpocząłeś ciekawy temat a odpowiedzi jak na lekarstwo.

Jakiś czas temu korzystałem jeszcze z biblioteki SimpleTest (dalej ST), którą opisywał chmolu w php Solutions. Przyznam, że nie wykorzystywałem wszystkich możliwości ST, nawet stubów. Były to proste testy z kilkoma assertami uruchamiane z poziomu eclipse dzięki wtyczce. Jakiś czas temu w pracy pojawił się temat php Unit 3. Przyznam, że podchodziłem do całości dość sceptycznie ponieważ pamiętam jeszcze wersję 2. i coś gdzie nie było nic specjalnego. Teraz php Unit to nowa jakość. Elastyczna architektura, przemyślane konstrukcje oparte na interfejsach nie wymuszające dziedziczenia, bardzo dobra (jeszcze rozwijana) dokumentacja. Bez problemu stworzyłem swojego ConsoleReportera (acz nie obyło się bez grzebania w kodzie). Niestety nie ma żadnego przełącznika by móc podać własne klasy (niby jest
Do instalacji itp korzystam z Phinga, ale raczej z tego względu, że nie ma nic innego, co by było bardziej sprawne i przyjemniejsze w obsłudze (vide Maven 2). Niestety wsparcie dla PU3 w Phingu jest jeszcze niezbyt dopierszczone i wymaga poprawek. Phinga używam również dlatego, że bądź co bądź jest w nim też wsparcie dla phpdoca. Niestety brakuje jakiegoś wielkiego repozytorium wtyk tak jak dla wcześniej wspomnianego Mavena.

Zatem moje odpowiedzi:
1. php Unit 3
2. brak, chociaż ST ma web-testera, acz nie korzystałem
3. Phing

@splatch - no właśnie nie bardzo miałem czas aby bliżej przyjrzeć się PHPUnit 3 mógłbyć w kilku zdaniach powiedzieć czym różni się od poprzednika? Od strony typowo programistycznej.
Co do SimpleTest i WebTestera, zdecydowanie wyprzedza go tutaj Selenium, pod wieloma względami. Boskie narzędzie. Planuje właśnie napisać Taska do Anta obsługującego selenium, jak się uda to się pochwalę.

Ale znalazłem coś równie ciekawego, zwie się jameleon.
Kompletne narzędzie do prowadzenia testów aplikacji. Szkoda, że dla Javy . Ale może uda się przeportować część rzeczy dla php :roll2:

My wykorzystujemy zestaw SimpleTest i SVN.
SimpleTest dlatego, że nie przepadam za uruchamianiem testów z lini komend, a nie trafiłem dotychczas na żaden wygodny interfejs pozwalajacy na odpalanie testów PHPUnit w przeglądarce (choć od razu przyznaję - nie szukałem za bardzo), pozwalajacy na odpalenie pojedynczego testu, określonej grupy testów lub wszystkich od razu.

Przewaga SVN jest raczej oczywista, a dodatkowo - wraz z połączeniem z TRAC'iem, któru od pewnego czasu lubię coraz mocniej, tworzy naprawdę silną platformę deweloperską.

Do webtesterów nie mogę się raczej przekonać. Może kiedyś

OT: Jesli mozna sie spytac - o jaki typ instalatora chodzi ? Swojego czasu widzialem na Sieci cos takiego. Byl plik setup.php a do tego skompresowana gzip, tar-em czy czyms innym paczka. W samej paczce byl plik XML ktory byl definicja tego jak ma dzialac caly ten instalator.

O cos takiego chodzi :?:

PS. Niestety moja skleroza nie pozwala mi sobie przypomniec jak to sie nazywalo.

A co sadzicie o updaterach dla aplikacji Myslicie ze to ma sens ? Cos takiego jak patche dla gier

@null, no właśnie jak używasz odpowiednich narzędzi to różnica pomiędzy instalacją, a upgradem jest znikoma.

Przykładowo co robi taki build.xml (na bazie Ant'a) przy instalacji naszych aplikacji (upgradzie):
1. Pobiera odpowiednią wersję z CVS do katalogu SRC,
2. Przeprowadza testy jednostkowe - jak się nie uda -> kończy instalacje i wysyła odpowiednie powiadomienia (via email),
3. Jeżeli testy jednostkowe przejdzie pomyślnie to: Apache STOP
4. Kopia obecnej aplikacji (wybranych katalogów, z wyłączeniem katalogów cache itp) z katalogu Web-App do BackUp-AKTUALNADATA
5. Kopia bazy danych (lub jeżeli jest to jakaś bardziej zaawansowany silnik bazy to różniczkowanie zmian)
6. Cały backup -> pakujemy zipem.
7. Tworzymy dokumentacje nowej aplikacji na bazie źródeł z katalogu SRC.
8. Wycinamy białe znaki itp z pobranych źródeł w katalogu SRC.
9. Kopiujemy SRC do Web-App, robimy update bazy.
10. Jeżeli są potrzebne jakieś zmiany w dotychczasowych plikach (np. config.php uprade sekcji version to je przeprowadzamy właśnie teraz.
11. Apache - Start
12. Sprzątamy katalog SRC, przenosimy Backupy na inny dysk itp.

Oprócz tego kilka innych (np. testy Apache Benchmark). Teraz zastanawiam się, jak po takiej instalacji (deploy, jak zwał tak zwał wiadomo o co chodzi), sprawdzić jeszcze z lotu ptaka czy niby całość się trzyma kupy

UPDATE:
@Dev, ale właśnie z tym testowaniem przez Web'a a z lini komend . Patrz, przy testach z lini komend możesz je odpalać kiedy chcesz i zbierać (przetwarzać) wyniki. Co więcej, im częściej je uruchamiasz tym lepiej.

Jak mniemam zanim stworzysz implementacje metody np. getNewsList tworzysz jej test. Im bardziej dopracowany test, tym lepiej np. tworzymy test który sprawdza czy getNewsList zwraca tablicę z kluczami odpowiednio id, title, lead, content itp, i czy pola te zawierają odpowiednią ilość znaków i czy są odpowiedniego typu. I teraz wyobraź sobie że całość podpinasz pod automat który raz na ustalony okres (np. co 5 minut) pobiera najnowszą wersję z repozytorium i ją testuje, a wynik testów przesyła wybranym osobom (z możliwością definicji poziomu raportowania itd). Deweloperzy odrazu wiedzą gdzie jest błąd. Poprawiają te błędy na bieżąco. Idąc dalej, zmieniają się wymagania Klienta, osoba odpowiedzialna za testy wprowadza zmianę w teście np. dodatkowe pole atachmentId -> test zwraca False bo w implementacji metody getNewsList tego nie ma, że o bazie nie wspomnę. Znowu rozchodzą się raporty, programiści odrazu przystępują do implementacji.
I to jest właśnie ciągła integracja, coś co staram się ostatnio wdrożyć i wychodzi nawet całkiem całkiem

Niestety - ale w moim zespole preferujemy inny tryb pracy z repozytorium i z kodem jako takim.
Polega on na tym, że jest wyraźny podział na zadania / bloki kodu które wykonują poszczególne osoby.
To one tworzą sobie również testy na potrzeby swojego kodu.
Dopiero gdy kod spełnia określone wymagania, jest wrzucany do repozytorium. Oczywiście - od tej zasady jest wiele wyjątków, nie zmienia to jednak faktu, że najczęstrzym sposobem uruchamiania testów polega na sprawdzeniu jednej klasy / biblioteki, a nie calości systemu.
W takim przypadku wyraźna wizualizacja tego, co sie dzieje, wraz z np. kolorowaniem komunikatów (tak jak w SimpleTest) jest bardzo przydatna, i pozytywnie wpływa na postęp prac i morale (widzisz, ile już ci się udało zrobić)

Jako, że ja zawsze się nie zgadzam i zawsze narzekam to i tym razem nie będzie inaczej

Widzę, że założyłeś "perfekcję" utworzonych testów. Z doświadczenia wiem (zespół 15 osobowy), że cięzko jest utworzyc dobre testy, biorace pod uwage kazda ewentualnosc. Moge sie zalozyc ze nie raz w tescie stworzonym przez Ciebie/Twoj team zdarzylo sie ze nie wzieto pod uwage jakiegos czynnika. To oczywiscie normalne. Mozna zredukowac to zjawisko korzystajac (w przypadku Javy) z narzedzi ktore juz w fazie analizy i projektowania dostarczaja nam polgotowe testy dla klas i metod. Wedlug mnie (a moge sie mylic) wlasnie od tych faz (tj analizy i projektowania) zalezy w glownej czesci w jakim stopniu wytworzone testy/wytworzony kod beda poprawne. Bo testy to nie wszystko. Testy moga wychwycic bledy w kodzie, nie wychwyca bledow funkcjonalnych (co z tego ze wiemy ze metoda zwroci to czy tamto nawet jesli zwracane dane beda spelnialy wzorzec to w kontekscie dzialajacej aplikacji moga byc bledne).

Tak jak DeyV, korzystam(y) z Trac'a i SVN'a. Deploy na jboss'a via ant'a. Kod zarzadzany jest w galeziach (kazda reprezentuje kolejny przyrost (iterację)).

Do tego nieodzowny Jude i JSwat i JUnit.

Pozdrawiam

@serafin - tak, ale przeznaczeniem testów jednostkowych nie jest jednoznaczne stwierdzenie, że aplikacja działa w 100% zgodnie z założeniami. Testy jednostkowe wspierają integrację aplikacji. Wprowadzasz nową funkcjonalność i wiesz w jaki sposób ona wpływa na pozostałe funkcjonalności.
Pozatym wszystko zależy od samego testu i umiejętności posiadanych przez osobę piszącą testy. My mówimy tutaj o prostych przypadkach, gdzie napisanie testu nie stanowi problemu (taki moduł aktualności ) a co przy tych dużo bardziej złożonych, tam też się pisze testy jednostkowe, tylko już na zupełnie innym poziomie.
Macie jakieś doświadczenia związane z autoamtyzacją pisania testów na bazie diagramów UML? Automatem, pół automatem? Serafin?

Automatem, owszem. Zeby nie byc goloslownym link:

http://www.objecteering.com/products_tests_for_java.php

Cheers

http://www.pake-project.com/ (nie działa, nie wiem czemu): http://72.14.221.104/search?q=cache:bhIqLL...pl&ct=clnk&cd=2

Fipaj: co ma piernik do wiatraka? Nie wypowiadaj się tam gdzie nie masz pojęcia o co chodzi Pozdro!

@serafin: ćśśśś Pake to narzędzie automatyzujące proces instalacji, rzeczywiście, nie czytałem całego wątku, odpowiedziałem tylko na zadane w pierwszym poście pytanie.
Jakkolwiek wątek zszedł na testowanie aplikacji, to jednak pierwsze pytanie pozostało bez odpowiedzi

// inna sprawa, że ta strona nie działa. cóż, może zaraz zacznie w każdym razie pake żyje, bo jest (chyba ;]) używany we frameworku symfony.

Pozdrawiam
PS. A żeby nie było, że nie mam pojęcia, o co chodzi, to osobiście uważam, że testowanie aplikacji niekiedy jest potrzebne

Testowanie aplikacji jest niezbedne do utrzymania odpowiedniej jakosci kodu i bezawaryjnosci dzialania aplikacji. Pomysl ze programista tworzy oprogramowanie do respiratora i nie testuje go dokladnie. Chcialbys byc podlaczony do takiego sprzetu z takim oprogramowaniem? Bo ja nie Tak samo jest z aplikacjami od ktorych wymaga sie wysokiej stabilnosci i tolerancji na bledy. Coprawda php czy java nie sa przeznaczone do softu na respirator ale chociazby Erlang ktory mnie bardzo fascynuje juz tak ;>

Pozdrawiam

Korzystał ktoś z phplint ?
Ciekaw jestem jak to rozwiazanie sprawdza sie w praktyce, np. w połaczeniu z phingiem.

patS