Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Zasady pisania na forum Pro

Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.

2 Stron V  < 1 2  
Reply to this topicStart new topic
> Testowanie aplikacji
LSM
post 4.12.2011, 15:36:32
Post #21





Grupa: Zarejestrowani
Postów: 64
Pomógł: 6
Dołączył: 20.03.2011
Skąd: Świdnica

Ostrzeżenie: (0%)
-----


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.

Ten post edytował LSM 4.12.2011, 15:38:30


--------------------
"I see" - said the blind man.
Go to the top of the page
+Quote Post
nasty
post 23.12.2011, 02:51:10
Post #22





Grupa: Zarejestrowani
Postów: 634
Pomógł: 14
Dołączył: 27.05.2006
Skąd: Berlin

Ostrzeżenie: (0%)
-----


Cytat(cojack @ 4.11.2011, 17:07:32 ) *
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.

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.
Go to the top of the page
+Quote Post
em1X
post 19.10.2013, 00:15:54
Post #23





Grupa: Zarejestrowani
Postów: 984
Pomógł: 41
Dołączył: 16.03.2002
Skąd: Płock

Ostrzeżenie: (0%)
-----


Cytat(.radex @ 30.04.2011, 21:51:20 ) *
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.


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


--------------------
eh, co polska wódka to polska wódka
Go to the top of the page
+Quote Post
zordon
post 26.05.2014, 13:24:04
Post #24





Grupa: Zarejestrowani
Postów: 358
Pomógł: 78
Dołączył: 4.11.2008
Skąd: Kraków

Ostrzeżenie: (0%)
-----


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.
Go to the top of the page
+Quote Post
Matrix12
post 3.08.2015, 20:42:52
Post #25





Grupa: Zarejestrowani
Postów: 144
Pomógł: 0
Dołączył: 22.03.2015

Ostrzeżenie: (0%)
-----


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 ?
Go to the top of the page
+Quote Post
Xelah
post 4.08.2015, 08:13:50
Post #26





Grupa: Zarejestrowani
Postów: 139
Pomógł: 24
Dołączył: 12.05.2013
Skąd: Hamburg

Ostrzeżenie: (0%)
-----


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.
Go to the top of the page
+Quote Post

2 Stron V  < 1 2
Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 19.03.2024 - 08:30