Na wniosek ActivePlayera, zakładam temat o testowaniu aplikacji. O to treść wątku:

Chciałbym porozmawiać na temat testowania aplikacji php. Czy testujecie swoje aplikacje? Jeśli tak, to jakich narzędzi używacie? Czy w firmach w których pracujecie wdrożone jest continuous integration? Jak w praktyce wygląda praca nad testowaniem aplikacji? Czy używacie testów jednostkowych? Uważam że temat testowania aplikacji to coś ciekawego, o czym stosunkowo mało w polskim internecie - mysle ze moze to byc ciekawy temat do dyskusji.

W świecie PHP mało kto używa CI (a nawet jeśli to nie przykłada do tego należytej uwagi).
Zacznijmy od tego, iż nie mając dosyć dobrze pokrytego kodu testami jednostkowymi nie ma co nawet iść w stronę CI (bo jaki w tym sens?)
A dlaczego nie pokrywają wszystkiego?
Ponieważ:
- nie umieją pisać niezależnych testów jednostkowych
- nie umieją korzystać z podstawowych dobrodziejstw takiego narzędzia jak PHPUnit (raporty w xmlu) - wiele razy widziałem "własne myki" na odpalanie testów które wynikają z braku wiedzy o funkcjonowaniu tego narzędzia
- zły projekt aplikacji powoduje ogromne trudności z jej testowaniem = nikomu nie chce się ich pisać przez co tworzenie ich jest zadaniem "dla kozła ofiarnego"
- Mockowanie/Stubowanie zbyt dużych fragmentów aplikacji = test jest prawie bezużyteczny
- Źle napisane testy (brak grup, brak czystego zdefiniowania testowanych funkcjonalności (tzw "samowalidujących") )

Staram się testować wszystko co mogę lecz nie zawsze jest na to czas (tak zbijcie mnie).
Nie stosuję TDD, ponieważ szczerze mówiąc projektuję w głowie a nie na "kartce" co potem może powodować dużo zmian w testach przed właściwą realizacją zadania.
Co do narzędzi to PHPUnit - najlepiej rozwinięte/rozwijane narzędzie do testów jednostkowych w PHP.

Testy funkcjonalne - ciężka sprawa ale Selenium jest dosyć wygodnie i używam go tylko do kluczowych funkcjonalności.

Z testowaniem aplikacji PHP jest jeden problem. PHPUnit ma ogromne zapotrzebowanie na pamięć i w przypadku odpalania testów na całej aplikacji potrafi zarżnąć serwer. I nie wynika to z braku wiedzy osób piszących testy, tylko z konstrukcji PHPUnit. Jeśli dodamy do tego całą "magię" Hudsona/Team City/innego dowolnego CI, okaże się, że dokładne testowanie aplikacji PHP to sztuka dla sztuki.

Serwery CI możesz skonfigurować naprawdę na duży limit pamięci w PHP. Także pamięć jest najmniejszym problemem.
Poza tym nie zaobserwowałem problemów z pamięcia przy testach. Zawsze można je podzielić na mniejsze cześci jeżeli zużycie pamięci rzeczywiście jest tak ogromne.

Konfiguracja konfiguracją, nie zapominaj jednak, że większość projektów PHP to projekty rozwijane "po kosztach" i inwestowanie w maszynę, która uradzi CI jest dodatkowym kosztem, który się nie zwróci.
Nie mam dużego doświadczenia jeśli chodzi o administrowanie CI, ale z tego co wiem, to nie można podzielić testowania danego builda na części. Build to build i powinien być testowany jako całość.

Nie wiem o jakiej formie builda mówisz ale można po prostu podać odpalanie kolejnych komend

Rozwiązuje problem.
Jeżeli ktoś robi projekt w php-cu po kosztach to na pewno nie stać go na pisanie testów jednostkowych.

Wreszcie jakiś nowy i ciekawy wątek w PRO, ale czy przyjemny haha, w to wątpie bo mało kto lubi pisać testy.
Bez PHPUnit się nie ruszam, ale bez bicia się przyznaje, że czasem brak czasu na napisanie testów.
Jednak większość projektów jest twardo otestowana, ale wszystkie testy jednostkowe powoli dopisuje.
Oczywiście mowie o najmniejszych klasach i modułach, bo to co najważniejsze jest 99% coverege.
Dla bezpieczeństwa własnego tyłka. Żeby podkolorować "szarą rzeczywistość nudnych testów", rzucę paroma linkami.

http://en.wikipedia.org/wiki/Behavior_Driven_Development
http://behat.org/ - BDD framework, dla php 5.3+. Naprawdę ciekawe cacko.

Zasadniczo działa to tak, że zanim napiszemy dany moduł/klasę whatever.
Opisujemy słownie jego zachowanie, które jest interpretowane przez specjalny parser Gherkin.
Przykład z http://docs.behat.org.



Szczerze to nie zgłębiałem się zbytnio w ten temat, napisałem tylko parę 'features' i szczerze polecam.
Nie wiem natomiast jak to dalej by z tym cudem bylo. (;

Kod źródłowy: https://github.com/Behat/Behat.

Na osobny wątek i post nadaję się Mink, alę to już zostawiam wam.
https://github.com/Behat/Mink.

Pozdrawiam.

A cóż takiego daje behat czego nie ma PHPUnit? (poza Gherkinem)
Oczywiście nie odbierz mnie źle po prostu pytam z ciekawości

Nie jestem ekspertem BDD, szczerze to dla mnie lekka egzotyka.
Ale z tego co wiem i sprawdziłem to zasadniczą różnicą jest podejście do pisania testów.
To jest nie tylko TDD, co właśnie BDD, najpierw opisujemy "zachowanie" aplikacji.
I według tego opisu przebiegają testy.
Nie mam pojęcia jak się to sprawdza przy zaawansowanych projektach czy nawet przykładach.
Projekt Behat jest bardzo świeży, ale już przyciągnął wiele osób.
Sam w "luźniejszym" okresie spróbuje coś konkretnego w nim stworzyć.
Pracowałem z nim dosłownie wieczór, ale było to nowe i całkiem przyjemne podejście do pisania kodu.

Pozdrawiam.

Aha. Musiałbym sprawdzić czy wnosi coś nowego co już wprowadza PHPUnit http://sebastian-bergmann.de/archives/738-...HPUnit-3.3.html

Co do BDD przydaje się do testów uczących + testowania łańcucha zdarzeń który w "zwykłych" testach jednostkowych raczej w ogóle nie występuje (tam sprawdzamy małe fragmenty, metody, prawie nigdy nie sprawdzamy "całości zachowania"), dlatego BDD sprawdza się w takim przypadku. No i jest niezwykle czytelne dla człowieka.

Natomiast cały czas odnoszę wrażenie że BDD jest jedynie dopełnieniem zwykłych testów jednostkowych "napisanych w TDD". Też tak odczuwacie?

Aczkolwiek dzięki za info, zanotuję

Jeśli chodzi o zapotrzebowanie PHPUnit na pamięć, problemem nie jest raczej sam PHPUnit, a to, co testujemy. Programiści przeważnie nie włączają izolacji procesów, albo nie wiedzą, że coś takiego istnieje, a jednocześnie całkowicie ignorują fakt, że jak referencje do obiektów tworzą cykle, to nawet PHP 5.3 nie zawsze im je usunie. Już nie wspomnę o stanach globalnych i innych cudach, które sprawiają, że po każdym teście w pamięci zostaje cała masa śmieci.

Duże zapotrzebowanie ze strony samego PHPUnita może wystąpić tylko przy zbieraniu informacji o pokryciu kodu testami, ale tu dane generuje akurat XDebug i to do niego trzeba mieć pretensje, że tego tyle jest .

Niestety nie testuję swoich aplikacji w takim stopniu w jakim prawdopodobnie powinienem, ale gdy testuję to:

* PHPUnit. Największy, najpopularniejszy, nie widziałem potrzeby szukania czegoś innego. Fajne raporty pokrycia. Bez snippetów w edytorze ani rusz — nie wyobrażam sobie wpisywać za każdym razem $this->assertEquals();
* Czasami TDD. Nie napisałem jeszcze zbyt wiele kodu przy użyciu TDD, więc może moja opinia się zmieni, ale jak do tej pory zdaje się to całkiem przydatną techniką. Potencjalny problem jest taki, że nie lubię zbyt wiele projektować na papierze i w konsekwencji podczas implementacji często znacznie zmieniam design klasy — co wymusza zmiany w testach.

U mnie za każdym razem wygląda to podobnie:) Piękne plany pisania testów kończą się na tym że testów nie ma, lub są napisane w bardzo wąskiej skali, a kluczowe i skomplikowane funkcje nie są przetestowane wcale. Problem wraca w momencie kiedy dla danego projektu potrzeba zmienić/dopisać trochę funkcji związanych z core, czy też logiką przechowywania danych, wtedy mam zawsze ten sam problem "Czy wszystko będzie działać?".

Powoli dochodzę do wniosku że selenium jest chyba najbardziej rozsądnym rozwiązaniem, ponieważ jeśli mądrze zrobimy testy, to wszystkie błędy "po środku" w kodzie zostaną wykryte.
Nawiasem ujmując nie znalazłem jeszcze jakiegoś sensownego sposobu aby po każdym otwarciu nowej strony jakoby z automatu szukać wystąpień warning'ów i notice'ów, które są zazwyczaj objawem problemów.

A czy macie przygotowane zwykłe checklisty, które wykonujecie przed przekazaniem projektu klientowi? Proste i trywialne sprawy typu: czy jest moje logo w stopce, czy kod się waliduje, czy podpiąłem crona, czy strona główna i kluczowe podstrony dobrze wyglądają w IE, FF, ... ? itd.

PS. Jakoś przegapiłem moment utworzenia wątpu więc trochę odkopuje dinozaura;-)

ja uzywam CI, zarowno w domu jak i w pracy:

- rozproszone CI na wielu vhostach
- hudson
- php rozne wersje
- linux, bsd, win

co do phpunit i pamieci to --process-isolation i po sprawie, inna kwestia do dlugosc wykonywania testow, powinno sie trzymac granicy 10minut na build, jezeli zajmuja dluzej to robic testy wieloetapowo.

ogolnie CI to temat rzeka, ostatnio pokazywalem CI w praktyce na krakspocie, ale to bylo tylko lizniencie tematu.

uzywam tego od ponad dwóch lat, i z pelna odpowiedzialnoscia moge polecic

Do swoich projektów w Symfony 1.4, używam wbudowanego lime do testowania. Teraz przyglądam się BDD, wygląda naprawdę ciekawie.

Obecnie w konfiguracji:
+ jednostkowe - PHPUnit
+ funkcjonalne - Selenium
+ budowanie aplikacji - Phing
+ CI - Jenkins

Zestaw sprawdza się fajnie, chociaż z wielu względów zastosowaliśmy SVN, zamiast któregoś z rozproszonych systemów kontroli wersji (git, bazaar).

Przy pracy większego zespołu przy skomplikowanym projekcie nie wyobrażam sobie pracy bez testów. Jak to powiedział jeden ze współpracowników: testy udowadniają, że w danym czasie dana funkcjonalność działała. Przy zmiennych, skomplikowanych wymaganiach biznesowych są potrzebne i nie raz ratują przed poważną wpadką.

Testy wymuszają także stosowanie pewnych dobrych wzorców np. ostatnio źle napisana, archaiczna autentykacja nie była testowana, trzeba było przepisać ten element, żeby wszystko dalej poszło zgodnie z planem i przy okazji załataliśmy poważną lukę bezpieczeństwa.

TDD jest fajne w specyficznych przypadkach np. jeżeli piszesz API albo crawlera, to nie ma nic lepszego.. jednak jestem zwolennikiem dobierania trybu pracy do zadania tzn. zaawansowany i hardkorowy debuging - XP, crawlery / API - TDD, większość projektu - Scrum, traktujący test jako integralną część realizacji zadania (bez niego nie może zostać zamknięte).


Testy funkcjonalne sprawdzają całość, testy jednostkowe poszczególne funkcje aplikacji. Oba są potrzebne np. freelancer do frontendu i AJAX , ale z drugiej strony crawlera nie przeklikasz.

Ważnym zagadnieniem jest pokrycie kodu testami. 100% to utopia w polskich realiach biznesowych, sztuką jest wybór elementów aplikacji, które ewidentnie muszą być testowane. CI - odkąd zacząłem z nim pracę, nie wyobrażam sobie innej opcji w większym projekcie.

Ostatnio trochę zainteresowałem się testami jednostkowymi z wykorzystaniem PHPUnit. Zastanawiam się tylko w jaki sposób mogę testować swoje aplikację. Przykładowo chcę zrobić test, który sprawdzi mi, czy poprawnie dodaje się użytkownik do bazy danych. Jak go zrobić, aby przeszedł test, ale jednocześnie nie zmienił np wartości w auto increment?? Może to zbyt ogólny test?

Tak samo np test na sprawdzanie poprawności wpisania danych w formularzu (mamy np ustawione w walidatorze, że masz przechodzić tylko tekst, ktoś zamienił, że tylko liczby, to test nie powinien tego przepuścić).

Jeśli łatwiej wykonać takie coś wykorzystując Zenda, to aplikacje piszę w Zendzie.

Ostatnio pisałem klasę kompozytową dla "drzewa danych". Bez testów miałem masę błędów z racji nagmatwanego kodu. Jak zacząłem robić testy i krok po kroku eliminowałem zagadnienia - to i kod się mega uprościł i podział na klasy ujednolicił. Jak dla mnie piękna sprawa ale faktem jest, że i firma musi być wyrozumiała i zdawać sobie sprawę z tego jakie są zalety TDD. One przychodzą z czasem. Mam doświadczenie w pracy w pewnej firmie o której myślałem bardzo pozytywnie, że czegoś się nauczę itp. Jednak gdy wspomniałem o TDD usłyszałem "nie mamy na to czasu proszę Pana tu się zarabia pieniądze". Pomyślałem - ok, całkowita racja. Ale przyszło mi wnikać w kody napisane przez mojego pracodawcę - i gdy robiłem małe poprawki w programie, jedynym sposobem na spr. czy wszystko działa OK było przeklikanie całego interfejsu. Po prostu żenada - gdyby były testy wystarczyłoby odpalić jeden link i po zabawie. Więc powstało pytanie: czy aby naprawdę na tym polega zarabianie pieniędzy ? W pojedynke może i tak, ale rozwój to praca z innymi ludźmi, a bez testów to nie robota, ale męczarnia w pracy grupowej.

Inna sprawa, że testy niejako wymuszają pisanie dobrego kodu który można łatwo potem dzielić na moduły itp. W tej firmie w ogóle nie było żadnych prywatnych bibliotek czy modułów, a firma ta działa już 15 lat na rynku. Zonk.

1) inicjujesz strukture i polaczenie z baza, ewentualnie ladujesz niezbedne dane do przeprowadzenia testu
2) tworzysz model uzytkownika, wstawiasz dane testowe
3) uruchamiasz obiekt ktory testujesz, ktorego zadaniem jest wstawienie usera do bazy
4) pobierasz usera z bazy jako nowa instancja modelu
5) sprawdzasz czy podane dane zgadzaja sie z testowymi (assert)



- kazdy test powinien pokrywac jeden przypadek
- walidator to osobny byt, testuje sie go osobno (single responsibility)

1) tworzysz obiekt request (dostepny w Zend_Test_PHPUnit_ControllerTestCase)
2) ustawiasz typ requestu na POST i wstawiasz dane formularza
3) dispatchujesz akcje kontrolera ($this->dispatch(...))
4) sprawdzasz czy uruchomiony zostal odpowiedni modul/kontroler/akcja
5) sprawdzasz czy walidacja dziala, czyli w tym przypadku: np: nie ma zapisu do bazy danych






imho to jest troche zalezne od profilu firmy, wiekszosc firm poprostu nie potrzebuje TDD bo tworzy krotko zyjace projekty, w ktorych ryzyko bledu jest wzglednie tolerowane.
Ale sa takze firmy w ktorych jakosc to podstawa i za to klienci placa ciezkie pieniadze, np: uruchamianie tych samych testow z automatu na 40 srodowiskach.
Poprostu wszystko wedlug potrzeb.

Robie z TDD i CI juz troche czasu i moja obserwacja jest taka, ze jak nie masz testow to w pozniejszym zyciu projektu mase czasu marnujesz na testowanie tego samego wkolko a bledy nadal sie pojawiaja, druga strona medalu jest taka, ze malo firm jest ktore maja dlugo zyjace projekty

Nie piszę testów jednostkowych jak mnie nikt do tego nie zmusi. Uważam że testy jednostkowe przy kodzie który jest poprawnie hermetyzowany, są zbędne. Tyle mam w tym temacie do powiedzenia.

Ok, ale hermetyczność nie jest w stanie uchronić przed pewnymi błędami, które są nieoczekiwane bo np. zmieni sie specyfika systemu zewnętrznego API, wtedy testy od razu wykryją, że komunikacja jest do bani - nie trzeba czekać na zgłoszenie od klienta, reakcja programisty jest szybsza. Jasne że można to też obsłużyć wyjątkiem i generowaniem komunikatu na telefon, że system nie tak działa bo wystąpił wyjątek. Jednak wtedy możes mieć przerost formy nad treścią bo okarze się, że co chwila musisz rzucić jakimś wyjątkiem.
Natomiast pisanie testów do każdego szczegółu jest marnotrawieniem czasu. Testy piszemy tam gdzie uważamy je za potrzebne i przydatne. Jednak dla mnie są one często pomocne gdy nie wiem jeszcze jak będzie wyglądać rozłożenie ról między klasami i chce sprawdzić komunikację - na różne sposoby, ale w implementacji, a nie na diagramie.

Testy jednostkowe nie są po to aby przetestować czy klasa poprawnie dziala a bardziej do tego czy klasa nadal poprawnie dziala wg. poprzednich zalozen. Jest to mechanizm pilnujacy kompatybilnosci wstecz.

Twoje częste zmiany implementacji spowodowane są właśnie brakiem pisania NAJPIERW testów jednostkowych.

Nikt chyba jeszcze nie wspomniał, że testy to rodzaj dokumentacji. Kiedy analizujesz nie swój bądź stary kod zamiast przeklikiwać przez podklasy często wystarczy obejrzenie testów, zwłaszcza funkcjonalnych, aby zrozumieć co dany kod robi, jak i dlaczego został stworzony.
Poza tym testy podczas pisania wyraźnie sygnalizują problem z designem kodu czy jego struktury. Główna zaleta TDD, chociaż osobiście rzadko używam tego podejścia - często wystarczy po prostu pisać testy na bieżąco. Jeśli nie jesteś w stanie przetestować jakiegoś fragmentu kodu bardzo często zaczynasz się zastanawiać, czy nie masz zbyt dużych zależności w kodzie, czy nie przydałoby się czegoś wstrzyknąć, wydzielić interface-u.
Testy to też nieodłączny atrybut refaktoringu. Ostatnio musiałem zrefaktoryzować spory fragment kodu odpowiedzialnego za budowanie zapytania SQL. To, że kod był dobrze pokryty testami oszczędziło mi naprawdę dużo stresu i pracy związanych z upewnianem się, że podczas dokonywania zmian nie popełniłem żadnych błędów, a query produkuje te same wyniki.
W firmie, której pracuję stosujemy ideę 'piramidy testów'. Liczba najprostszych(jednostkowych) testów powinna być jak największa i maleć w kolejnych warstwach, które testują większe, cięższe fragmenty aplikacji.
Tak więc nasza piramida wygląda tak:
- testy selenium
- testy 'akceptacyjne' - wykorzystanie prawdziwych webservice'ów, wewnętrznych żądań http, z podłożonym stanem bazy
- testy integracyjne - mockowanie webservice'ów, żądań http, ale wykorzystywanie podłożonego stanu bazy jeśli jest to konieczne
- testy jednostkowe, zarówno php jak i js. Generalna zasada to traktowanie pojedynczej klasy jako unit i mockowanie praktycznie całego 'świata zewnętrznego', oczywiście tam, gdzie ma to sens i jest to możliwe. W przypadku testów js czasami stosujemy bardziej funkcjonalne podejście, np gdy js polega na DOM-ie.

Ogólne podejście do testów w świecie php jest takie, że mało kogo na nie stać. Jedynie największe firmy i/lub bazujące długofalowo na jednym produkcie musi zapewnić odpowienią jakość i rozumie korzyści z tego płynące. Ubolewam nad tym, że stanowczo zbyt wiele projektów bazuje dziś na podejściu 'startupowym', gdzie liczy się tworzenie maksymalnej liczby ficzerów w najmniejszym możliwym czasie. Przy takim podejściu nie ma miejsca na testy, co później kończy się tak jak w przypadku firmy, w której byłem kiedyś na rozmowie: startup, który odpalił i istniał już chwilę na rynku w końcu dotarł do momentu, w którym zaczął się rozpadać, a szefostwo było w stanie zaproponować kosmiczne pieniądze komuś, kto ogarnie ten burdel tak żeby jego popularność (ruch) go nie zjadły.

A czy BDD to nie rozszerzenie dla TDD ? Według mnie wystarczy sam PHPSpec, przetestuje nam aplikacje czy zwraca odpowiedni wynik wiec po co unit testy ?

Bo testy jednostkowe a integracyjne czy funkcjonalne to kompletnie inne rzeczy. Testy jednostkowe sprawdzają architekturę pojedyńczych elementów a nie działanie aplikacji jako całości.

Możba potraktować BDD jako rozszerzenie dla TDD ale to nie ma niczego wspólnego z obecnością czy nie testów jednostkowych.