Marcin
Molga
Senior Solution
Architect, IBM.
Temat: zarobki
Jakub Rajchowiak:
a wracajac do "unit testow" jak w praktyce je wykonujecie??
W zasadzie unit testy to tylko jeden z kroków w maszynce pod tytułem 'release management' :)
U nas zwykle wygląda to tak:
1. Deweloperzy dostają specyfikację przypadków użycia (zarówno diagramy UML, jak i opisy) i uzgodnione z klientem prototypy ekranów. Do tego w stałej dyspozycji zostaje Product Manager ('w stałej dyspozycji' może oznaczać mail/Skype/tel :) w celu wyjaśniania ewentualnych wątpliwości ad hoc.
2. Na podstawie UC przygotowują klasy i metody testowe.
3. Po przygotowaniu testów piszą klasy implementujące logikę biznesową danego UC.
4. Po zaimplementowaniu fragmentu logiki uruchamiają testy na lokalnych maszynach (Maven, do tego JUnit/PHPUnit - bardzo ładnie się integruje z Eclipse).
5. Po pomyślnym przejściu testów commit funkcjonalności do Mercuriala/SVN a testy do wspólnego repozytorium testów. W przeciwnym wypadku deweloper dostaje raporty o nieudanych testach - która metoda, itp. Wtedy wprowadza poprawki w implementacji logiki, uruchamia ponownie testy itd.
Poza tym do przygotowywania buildów i ich deploymentu na serwery (testowe, preprodukcyjne, produkcyjne) używamy zwykle TeamCity/Hudsona i Mavena (nie ma znaczenia, czy aplikacja jest PHP czy J2EE). Jednym z obowiązkowych kroków w przygotowaniu builda jest pobranie najnowszej wersji z Mercuriala/SVNa i uruchomienie wszystkich testów: jak nie przejdą, nie ma builda.
Jest spory wybór narzędzi, większość można wygodnie uruchamiać z Eclipse. Żeby skonfigurować taką maszynkę do automagiczengo przygotowywania buildów (inkrementacja wersji, tagowanie w repo, testy, liquibase, deployment, raportowanie itp.) trzeba poświęcić ze dwa tygodnie, ale IMHO warto - w znacznym stopniu eliminuje kretyńskie błędy i oszczędza czas. No, chyba że jak zauważył Marceli, projekt składa się z 5-6 podstron :)
Pozdrawiam.