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
nospor
post 26.04.2011, 08:44:53
Post #1





Grupa: Moderatorzy
Postów: 34 868
Pomógł: 5802
Dołączył: 27.12.2004




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.


--------------------

Najlepsze kawałki programistyczne || Dowcipy o informatykach || Forum PHP dla opornych
Klasy: Pager (stronicowanie) | Cache | ShoutBox (Chat) | Widok | Ładne url'e

"Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista
"Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer

Go to the top of the page
+Quote Post
wookieb
post 26.04.2011, 09:02:10
Post #2





Grupa: Moderatorzy
Postów: 8 989
Pomógł: 1550
Dołączył: 8.08.2008
Skąd: Słupsk/Gdańsk




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.


--------------------
Go to the top of the page
+Quote Post
batman
post 26.04.2011, 09:21:57
Post #3





Grupa: Moderatorzy
Postów: 2 913
Pomógł: 267
Dołączył: 11.08.2005
Skąd: 127.0.0.1




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.


--------------------
I would love to change the world, but they won't give me the source code.
My software never has bugs. It just develops random features.
--------------------
blog
Kuchnia Kopytka
www.wykangurzeni.pl
Go to the top of the page
+Quote Post
wookieb
post 26.04.2011, 09:26:58
Post #4





Grupa: Moderatorzy
Postów: 8 989
Pomógł: 1550
Dołączył: 8.08.2008
Skąd: Słupsk/Gdańsk




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.


--------------------
Go to the top of the page
+Quote Post
batman
post 26.04.2011, 10:02:42
Post #5





Grupa: Moderatorzy
Postów: 2 913
Pomógł: 267
Dołączył: 11.08.2005
Skąd: 127.0.0.1




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ść.


--------------------
I would love to change the world, but they won't give me the source code.
My software never has bugs. It just develops random features.
--------------------
blog
Kuchnia Kopytka
www.wykangurzeni.pl
Go to the top of the page
+Quote Post
wookieb
post 26.04.2011, 10:05:29
Post #6





Grupa: Moderatorzy
Postów: 8 989
Pomógł: 1550
Dołączył: 8.08.2008
Skąd: Słupsk/Gdańsk




Nie wiem o jakiej formie builda mówisz ale można po prostu podać odpalanie kolejnych komend
Kod
phpunit katalog/z/testem/modulu
phpunit katalog/z/testem/drugiego/modulu

// albo
phpunit --group GrupaTestowa

...

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


--------------------
Go to the top of the page
+Quote Post
pejott
post 27.04.2011, 18:49:40
Post #7





Grupa: Zarejestrowani
Postów: 81
Pomógł: 4
Dołączył: 15.02.2009

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


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.

Kod
Feature: Search courses
    In order to ensure better utilization of courses
    Potential students should be able to search for courses

Scenario: Search by topic
    Given there are 240 courses which do not have the topic "biology"
    And there are 2 courses A001, B205 that each have "biology" as one of the topics
    When I search for "biology"
    Then I should see the following courses:
        | Course code |
        | A001        |
        | B205        |


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.
Go to the top of the page
+Quote Post
wookieb
post 27.04.2011, 19:06:02
Post #8





Grupa: Moderatorzy
Postów: 8 989
Pomógł: 1550
Dołączył: 8.08.2008
Skąd: Słupsk/Gdańsk




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


--------------------
Go to the top of the page
+Quote Post
pejott
post 27.04.2011, 19:11:35
Post #9





Grupa: Zarejestrowani
Postów: 81
Pomógł: 4
Dołączył: 15.02.2009

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


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.
Go to the top of the page
+Quote Post
wookieb
post 27.04.2011, 21:41:25
Post #10





Grupa: Moderatorzy
Postów: 8 989
Pomógł: 1550
Dołączył: 8.08.2008
Skąd: Słupsk/Gdańsk




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ęsmile.gif
Powód edycji: [wookieb]: [wookieb]:


--------------------
Go to the top of the page
+Quote Post
Zyx
post 30.04.2011, 07:36:25
Post #11





Grupa: Zarejestrowani
Postów: 952
Pomógł: 154
Dołączył: 20.01.2007
Skąd: /dev/oracle

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


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 smile.gif.


--------------------
Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0
Go to the top of the page
+Quote Post
.radex
post 30.04.2011, 20:51:20
Post #12





Grupa: Zarejestrowani
Postów: 1 657
Pomógł: 125
Dołączył: 29.04.2006

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


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.


--------------------
blog | Tadam — minutnik do Pomodoro na Maka :)
Go to the top of the page
+Quote Post
ActivePlayer
post 1.06.2011, 09:22:28
Post #13





Grupa: Przyjaciele php.pl
Postów: 1 224
Pomógł: 40
Dołączył: 6.07.2004
Skąd: Wuppertal

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


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;-)

Ten post edytował ActivePlayer 1.06.2011, 09:23:17
Go to the top of the page
+Quote Post
cepa
post 8.06.2011, 22:49:40
Post #14





Grupa: Zarejestrowani
Postów: 125
Pomógł: 7
Dołączył: 27.01.2010

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


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 smile.gif


--------------------
Go to the top of the page
+Quote Post
Ormin
post 28.06.2011, 14:31:38
Post #15





Grupa: Zarejestrowani
Postów: 64
Pomógł: 0
Dołączył: 3.02.2009

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


Do swoich projektów w Symfony 1.4, używam wbudowanego lime do testowania. Teraz przyglądam się BDD, wygląda naprawdę ciekawie. smile.gif
Go to the top of the page
+Quote Post
Hellz
post 29.06.2011, 18:16:35
Post #16





Grupa: Zarejestrowani
Postów: 17
Pomógł: 0
Dołączył: 1.01.2007

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


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).

Cytat
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.

Testy funkcjonalne sprawdzają całość, testy jednostkowe poszczególne funkcje aplikacji. Oba są potrzebne np. freelancer do frontendu i AJAX wink.gif, 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.


--------------------
O mnie: Krzysztof Zalasa na LinkedIn
Go to the top of the page
+Quote Post
IceManSpy
post 27.08.2011, 16:02:15
Post #17





Grupa: Zarejestrowani
Postów: 1 006
Pomógł: 111
Dołączył: 23.07.2010
Skąd: Kraków

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


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.


--------------------
Go to the top of the page
+Quote Post
LSM
post 25.09.2011, 22:37:05
Post #18





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

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


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. nerdsmiley.png


--------------------
"I see" - said the blind man.
Go to the top of the page
+Quote Post
cepa
post 27.10.2011, 08:15:46
Post #19





Grupa: Zarejestrowani
Postów: 125
Pomógł: 7
Dołączył: 27.01.2010

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


Cytat(IceManSpy @ 27.08.2011, 17:02:15 ) *
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?


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)

Cytat(IceManSpy @ 27.08.2011, 17:02:15 ) *
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ć).


- 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



Cytat(LSM @ 25.09.2011, 23:37:05 ) *
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. nerdsmiley.png



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 smile.gif


--------------------
Go to the top of the page
+Quote Post
cojack
post 4.11.2011, 16:07:32
Post #20





Grupa: Zarejestrowani
Postów: 898
Pomógł: 80
Dołączył: 31.05.2008

Ostrzeżenie: (20%)
X----


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.


--------------------
cojack blog - mój blog (na jakiś czas off).
"jak czegoś nie wiem, to nie myślę że wiem" - moja domena
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: 16.12.2019 - 06:47