Testowanie aplikacji Opcje

[nospor]

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.

[zordon]

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.