produktywność w JEE
Michał Trzcinka
Nazywam się Michał Trzcinka, mam 22 lata, studiuję informatykę i ekonometrię (III rok) i zajmuję się developmentem w Javie (+
zupełnie hobbistycznie w Rubym).
Chciałbym podjąć na tej liście pewien temat, o którym myślę od dłuższego czasu. Podczas pracy z "korporacyjną" Javą zauważam jeden
znaczący minus względem języków (i opartych na nich frameworków/bibliotek) interpretowanych (PHP, Ruby on Rails itp.): konieczność
przekompilowywania oraz "redeployowania" w serwerach aplikacji/kontenerach webowych.
Jest to pewien narzut na wydajność: w takim RoR np. możemy zmienić linijkę kodu i wystarczy odświeżyć przeglądarkę, natomiast w
Javie trzeba cierpliwie czekać na kompilację i redeployment. Powoduje to, że czasem pisze się kod, który sprawdzamy nawet po kilku
godzinach (dla oszczędności czasu). Nie mówię już o testach, na których kompilację też trzeba czekać.
Zdaję sobie sprawę, że wynika to z natury języka, który jest kompilowany, a nie interpretowany. Jednak czy są jakieś alternatywne
podejścia zwiększające produktywność w Javie? Jakieś dynamiczne kontenery webowe, które bez problemu radzą sobie z wielokrotnym
podmienianiem WARów bez konieczności restartu? Macie jakieś pomysły, doświadczenia w tym zakresie? A może macie jakieś własne
sposoby na czekanie na kompilację/deployment? ;)
--
pozdrawiam,
Michał Trzcinka
http://trzcinka.blogspot.com
Leonard Milcin
> Witam wszystkich :) Nazywam się Michał Trzcinka, mam 22 lata,
> studiuję informatykę i ekonometrię (III rok) i zajmuję się
> developmentem w Javie (+ zupełnie hobbistycznie w Rubym). Chciałbym
> podjąć na tej liście pewien temat, o którym myślę od dłuższego czasu.
> Podczas pracy z "korporacyjną" Javą zauważam jeden znaczący minus
> względem języków (i opartych na nich frameworków/bibliotek)
> interpretowanych (PHP, Ruby on Rails itp.): konieczność
> przekompilowywania oraz "redeployowania" w serwerach
> aplikacji/kontenerach webowych. Jest to pewien narzut na wydajność: w
> takim RoR np. możemy zmienić linijkę kodu i wystarczy odświeżyć
> przeglądarkę, natomiast w Javie trzeba cierpliwie czekać na
> kompilację i redeployment. Powoduje to, że czasem pisze się kod,
> który sprawdzamy nawet po kilku godzinach (dla oszczędności czasu).
> Nie mówię już o testach, na których kompilację też trzeba czekać.
No cóż, sam wyjaśniłeś. Programowanie ,,na pałę'' nie wróży nic dobrego.
Jeśli nie wiesz co piszesz w jaki sposób możesz być pewny, że twój
program będzie prawidłowo zachowywał się w każdej sytuacji? Fakt, że
twój kod się kompiluje a aplikacja się uruchamia i coś tam działa nie
oznacza bynajmniej, że działa poprawnie.
> Zdaję sobie sprawę, że wynika to z natury języka, który jest
> kompilowany, a nie interpretowany. Jednak czy są jakieś alternatywne
> podejścia zwiększające produktywność w Javie? Jakieś dynamiczne
> kontenery webowe, które bez problemu radzą sobie z wielokrotnym
> podmienianiem WARów bez konieczności restartu? Macie jakieś pomysły,
> doświadczenia w tym zakresie? A może macie jakieś własne sposoby na
> czekanie na kompilację/deployment? ;)
W teorii można takie rzeczy robić (np. http://www.zeroturnaround.com/)
ja jednak proponuję bardziej konserwatywne podejście. Nic nie zastąpi
przemyślenia tego co się robi. Lubię pisać np. cały dzień po to by
uruchomić wszystko w kilka minut przed wyjściem z pracy. Daje mi to
dodatkową satysfakcję i pomaga mi w utrzymaniu pewności, że wiem co robię.
Pozdrawiam,
Leonard
Łukasz Lichota
zgadzam się z Tobą że ten redeploy jest męczący i traci się trochę
czasu przez to,
z drugiej strony w językach interpretowanych jest innego rodzaju minus
czyli taki że dopóki czegoś nie wykonasz to nie wiesz że masz błąd,
dajmy na to że piszesz w Rubym i zmieniłeś coś w kodzie który jest
używany na wielu stronach, żeby sprawdzić czy to działa musiałbyś je
wszystkie wyświetlić (załóżmy że kod jest wykonywany w różnych
kontekstach) przez co też tracisz czas, w przypadku języków
kompilowanych chociaż część błędów odpada Ci na etapie kompilacji,
nie mam jednak doświadczenia w językach interpretowanych dlatego
chętnie usłyszę od Ciebie czy taki problem występuje,
co można na to poradzić w Javie? w pewnych przypadkach mogą pomóc unit
testy, jeśli akurat piszesz kod o jakiejś wyodrębnionej
funkcjonalności to mały test JUnitowy pozwoli Ci szybko go testować
bez redeploya,
podobnie jeśli masz większy system który będziesz często modyfikował
to napisanie paru testów jednostkowych też może się szybko zwrócić,
także polecam testy jeśli piszesz kod bardziej funkcjonalny, w
przypadku kodu warstwy prezentacji to chyba testy dają dużo mniej
pozdrawiam
Lukasz
Paweł Stawicki
aplikacji z wara. Możesz ze zwykłego katalogu, który zawiera dokładnie
to samo co WAR po rozpakowaniu, czyli m.in. katalog classes. I taki
classes możesz podlinkować (przynajmniej pod linuxem ;)) pod swój bin
z eclipse'a czy inny katalog z wynikami kompilacji z Twojego
ulubionego IDE.
Można też tak skonfigurować tomcata, żeby nie deployować mu aplikacji
do jego katalogu webapps, tylko jakoś inaczej powiedzieć mu że ma taką
to a taką aplikację na takim kontekście, i skąd ma brać skompilowane
klasy. Dawno nie używałem, ale pamiętam że plugin sysdeo do eclipse'a
takie rzeczy potrafi.
Pozdrawiam
Paweł Stawicki
Michał Pawluk
zautomatyzowanie całego procesu za pomocą skryptu ANT.
Kolejne przykładowe targety:
kasowanie plików z poprzedniej kompilacji,
bieżąca kompilacja,
stworzenie wara,
kopiowanie wara do odpowiedniego folderu lub można skopiować pliki luzem.
Każdy target można odpalić osobno albo całą serię.
Pozdrawiam Michał Pawluk
Paweł Stawicki pisze:
Radoslaw H. Urbas
mvn jetty:run-war
Wtedy nie trzeba robic programowania w ANT ;-)
Pozdrawiam,
--
Radoslaw H. Urbas
____________________________
mail radosla...@gmail.com
homepage http://urbas.tk/
Paweł Stawicki
>> zautomatyzowanie całego procesu za pomocą skryptu ANT.
>> Kolejne przykładowe targety:
>> kasowanie plików z poprzedniej kompilacji,
>> bieżąca kompilacja,
>> stworzenie wara,
>> kopiowanie wara do odpowiedniego folderu lub można skopiować pliki luzem.
Tylko że właśnie to kasowanie, kompilowanie, pakowanie do wara itd. trwa...
Pozdrawiam
Paweł Stawicki
http://pawelstawicki.blogspot.com
Michał Trzcinka
>> Mnie się wydaje, że też nie najgorszym rozwiązaniem jest
>> zautomatyzowanie całego procesu za pomocą skryptu ANT.
>> Kolejne przykładowe targety:
>> kasowanie plików z poprzedniej kompilacji,
>> bieżąca kompilacja,
>> stworzenie wara,
>> kopiowanie wara do odpowiedniego folderu lub można skopiować pliki luzem.
>
> Tylko że właśnie to kasowanie, kompilowanie, pakowanie do wara itd. trwa...
>
>
Podejście z uruchamianiem aplikacji nie z WARa, ale z katalogu gdzie kompilator w locie aktualizuje skompilowane pliki, wydaje się
być dużo bardziej ergonomiczne (czyli to, które opisał Paweł wcześniej).
--
pozdrawiam,
Michał Trzcinka
Leonard Milcin
>>> Mnie się wydaje, że też nie najgorszym rozwiązaniem jest
>>> zautomatyzowanie całego procesu za pomocą skryptu ANT.
>>> Kolejne przykładowe targety:
>>> kasowanie plików z poprzedniej kompilacji,
>>> bieżąca kompilacja,
>>> stworzenie wara,
>>> kopiowanie wara do odpowiedniego folderu lub można skopiować pliki luzem.
>
> Tylko że właśnie to kasowanie, kompilowanie, pakowanie do wara itd. trwa...
Nikt nie mówi, że trzeba kasować wszystko i kompilować od nowa. Ja
zrobiłem sobie skrypt dla Ant-a który używam z ew. drobnymi zmianami we
wszystkich projektach. Kompiluje tylko te klasy które się zmieniły a
następnie robię update wynikowego archiwum bez konieczności tworzenia go
od zera.
Wszystko jest w manualu dla Ant-a.
Pozdrawiam,
Leonard
Michał Trzcinka
>
> Nikt nie mówi, że trzeba kasować wszystko i kompilować od nowa. Ja
> zrobiłem sobie skrypt dla Ant-a który używam z ew. drobnymi zmianami we
> wszystkich projektach. Kompiluje tylko te klasy które się zmieniły a
> następnie robię update wynikowego archiwum bez konieczności tworzenia go
> od zera.
No tak, ale kontener i tak musi to wynikowe archiwum rozpakować. Poza tym, kontenery różnie radzą sobie z aktualizowaniem
aplikacji w locie (taki Tomcat może tylko kilka razy a potem się wywala). Narzędzie, o którym wspomniałeś wcześniej (JavaRebel)
wygląda bardzo obiecująco, testowałem sobie chwilę i muszę przyznać, że jestem pod wrażeniem ;)
--
pozdrawiam,
Michał Trzcinka
Kazimierz Pogoda
> Podejście z uruchamianiem aplikacji nie z WARa, ale z katalogu gdzie kompilator w locie aktualizuje skompilowane pliki, wydaje się
> być dużo bardziej ergonomiczne (czyli to, które opisał Paweł wcześniej).
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
Chodzi o atrybut reloadable. O ile pamiętam twórcy jetty obcieli ten
feature twierdząc że jest to security hole (problemy z naturą
classloaders) i choć jetty się świetnie osadza w innych narzędziach
(maven), to do "live webapplication development" nadaje się przez to
dosyć słabo. Choć są projekty które znalazły na to workaround - np.
cocoon.
http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/1297_1_1.html
Jeśli używasz eclipse, to nie masz się o co martwić - po założeniu
nowego "Dynamic Web Project" wszystko działa "out of the box" tak jak
sobie tego życzysz i nawet wara będzie później z tego budować bez
żadnego anta czy mavena (dobre na początek). Jedyny minus - trzeba się
wpisać w pewną konwencję co do struktury katalogów w projekcie.
--
"Meaning is differential not referential"
kazik 'morisil' pogoda
http://www.xemantic.com/ http://blog.xemantic.com/
Paweł Stawicki
> nowego "Dynamic Web Project" wszystko działa "out of the box" tak jak
> sobie tego życzysz
No nie koniecznie. Jeśli używasz go z JBossem, to robi eara za każdym
razem i go "publishuje". Ja właśnie przy pracy z jbossem zrobiłem
sobie zamiast eara katalog z rozszerzeniem .ear i w nim pliki z
rozszerzeniem jar/war i w nich linki. Działa super :)
Pawel Debski
> wszystkie wyświetlić (załóżmy że kod jest wykonywany w różnych
> kontekstach) przez co też tracisz czas, w przypadku języków
Chciałbym stanowczo zaprotestować przeciwko plotkom jakoby unit testy
były rzeczą specyficzną dla Javy.
Niezależnie od wykorzystywanych narzędzi każdy duży, długo żyjący system
powinien być obłożony odpowiednią liczbą unit testów.
W szczególności w powyższym przypadku każdy poważny projektant systemu
powinien przewidzieć odpowiednią liczbę przypadków testowych w JWebUnit,
Cactusie, QuickTeście lub czymś podobnym.
--
Z powazaniem / Best Regards /
Mit freundlichen Gruessen / Meilleures salutations
Pawel Debski
Managing Consultant, e-mail: PDe...@econsulting.pl
Tel. 0048-504-766-316, 0048-22-730-2794
eConsulting Sp. z o. o. http://econsulting.pl
Kochanowskiego 3, Pruszkow, KRS 0000098514
NIP PL534-2194-317, kapital 150000PLN
Biuro W-wa: Ciolka 12/401, 0048-22-463-6357
stallman
On Jun 23, 10:16 am, Pawel Debski <pdeb...@econsulting.pl> wrote:
> Chciałbym stanowczo zaprotestować przeciwko plotkom jakoby unit testy
> były rzeczą specyficzną dla Javy.
używane.
> Niezależnie od wykorzystywanych narzędzi każdy duży, długo żyjący system
> powinien być obłożony odpowiednią liczbą unit testów.
zdaniem razem z nimi powinny być tworzone
testy funkcjonalne wyprodukowanych features. Dzięki takim narzędziom
jak Selenium, Watir etc. jest to w miarę dla aplikacji webowych.
>W szczególności w powyższym przypadku każdy poważny projektant systemu
>powinien przewidzieć odpowiednią liczbę przypadków testowych w JWebUnit,
>Cactusie, QuickTeście lub czymś podobnym.
Javowych :).
Piotr Paradziński
O tym z kolei ja nie słyszałem TNXE6 stallman
Pawel Debski
>> powinien być obłożony odpowiednią liczbą unit testów.
> Tak, tyle że testy jednostkowe będą testowały logikę aplikacji. Moim
To chyba tym lepiej? Czyż juzer nie jest zainteresowany tym jak działa
program, a nie co jest w środku?
> zdaniem razem z nimi powinny być tworzone
> testy funkcjonalne wyprodukowanych features. Dzięki takim narzędziom
Testy jednostkowe w sensie JUnit (np. test case konkretnej metody) jest
jednak moim zdaniem metodą pośrednią osiągnięcia wysokiej jakości
produktu finalnego.
Testy wychodzące od przypadków użycia (UML use cases) czy ogólniej - od
specyfikacji funkcjonalnej - są moim zdaniem lepszą, bo bardziej
bezpośrednią, metodą osiągnięcia tej jakości.
Zwróćcie uwagę, że obie metody się nie wykluczają, choć na ogół ich
równoległe stosowanie jest bardzo kosztowne. (zwłaszcza biorąc pod uwagę
aktualne oczekiwania płacowe programistów :-)
--
Z powazaniem / Best Regards /
Mit freundlichen Gruessen / Meilleures salutations
Pawel Debski
Managing Consultant, e-mail: PDe...@econsulting.pl
Tel. 0048-504-766-316, 0048-22-730-2794
eConsulting Sp. z o. o. http://econsulting.pl
Kochanowskiego 3, Pruszkow, KRS 0000098514
NIP PL534-2194-317, kapital 150000PLN
Biuro W-wa: Ciolka 12/401, 0048-22-463-6357
To join us: cv (o) econsulting (!) pl
To contract us: salesteam (o) econsulting (!) pl
Piotr Paradziński
> jednak moim zdaniem metodą pośrednią osiągnięcia wysokiej jakości
> produktu finalnego.
testy jednostkowe dają pewność że przejście (lub nie przejście) testów
funkcjonalnych jest regułą a nie wyjątkiem a dzięki temu znacznie
obniżają koszty utrzymania i dodawania/modyfikacji funkcjonalności (a
programiści z utrzymania mają mniej wrzodów żołądka :) wiem coś o tym)
> Testy wychodzące od przypadków użycia (UML use cases) czy ogólniej - od
> specyfikacji funkcjonalnej - są moim zdaniem lepszą,
zastąpienie testów funkcjonalnych przez testy jednostkowe to bardzo
odważny i śmiały pomysł ;)
> (...) choć na ogół ich
> równoległe stosowanie jest bardzo kosztowne.
takie sławy programistyczne jak K. Beck czy M. Fowler mówią że używają
testów jednostkowych by zwiększyć swoją efektywność (programiści
czytają: by być bardziej za~!@#stymi programistami, managerowie: by
więcej pracy o lepszej jakości było wykonane w tym samym czasie), z
moich obserwacji wynika, iż kto nie spróbował twierdzi że są zbyt
kosztowne, kto spróbował używa bez względu czy jego PM o tym wie czy
nie
> (zwłaszcza biorąc pod uwagę
> aktualne oczekiwania płacowe programistów :-)
konsultant narzekający na płace programistów i na ich produktywność - ROTFL
--
Piotr Paradziński
http://groups.google.com/group/lublin-jug
http://it-researches.blogspot.com
Adam
Whats the difference between a used car salesman and a software salesmen?
The used car salesman knows when he's lying.
to jakby ktoś się zapędził w ufaniu testom ;]
--
pozdrawiam
Adam Kędziora
stallman
On Jun 23, 7:12 pm, Pawel Debski <pdeb...@econsulting.pl> wrote:
> >> Niezależnie od wykorzystywanych narzędzi każdy duży, długo żyjący system
> >> powinien być obłożony odpowiednią liczbą unit testów.
> > Tak, tyle że testy jednostkowe będą testowały logikę aplikacji. Moim
>
> To chyba tym lepiej? Czyż juzer nie jest zainteresowany tym jak działa
> program, a nie co jest w środku?
sformułowałem). Jednak uważam że usera(chyba że user==programista( nie
obchodzi że projekt przechodzi testy jednostkowe. Usera interesuje to
czy system spełnia jego oczekiwania czyli czy odpowiada właściwie na
konkretne scenariusze. A jak sam zobaczysz - Selenium posiada
mechanizm który pozwala na łatwe wytworzenie testów samemu userowi.
> Testy jednostkowe w sensie JUnit (np. test case konkretnej metody) jest
> jednak moim zdaniem metodą pośrednią osiągnięcia wysokiej jakości
> produktu finalnego.
> Testy wychodzące od przypadków użycia (UML use cases) czy ogólniej - od
> specyfikacji funkcjonalnej - są moim zdaniem lepszą, bo bardziej
> bezpośrednią, metodą osiągnięcia tej jakości.
jednostkowe były ważne de facto tylko dla programistów i jakkolwiek
one nie byłyby stworzone nie mogły sprawdzić wszystkiego. Do każdego
UseCase był tworzony odpowiedni scenariusz w Selenium i dzięki temu
zdobywaliśmy szersze spojrzenie na system który tworzymy (a nie
tworzylismy go od samego poczatku tylko przejelismy) którego nie
dawały nam testy jednostkowe bo nie od tego one są :).
> Zwróćcie uwagę, że obie metody się nie wykluczają, choć na ogół ich
> równoległe stosowanie jest bardzo kosztowne. (zwłaszcza biorąc pod uwagę
> aktualne oczekiwania płacowe programistów :-)
stosowania) bo one nie odpowiadają czy dany feature działa tak jak
oczekiwał klient tylko czy klasy i funkcje działają w pewnych
parametrach poprawnie. Testy jednostkowe - sprawa indywidualna
programisty (uważam że powinien je stosować). Testy funkcjonalnościowe
- obowiązkowe testy które powinien przeprowadzać użytkownik systemu
(lub tester) i sprawdzać czy system spełnia to co jest zrobione w use
case albo co nie zostało dobrze przemyślane.
(offtopic) Odnośnie płacy - wolisz zapłacić programiście mniej
pieniędzy i mieć błąd w systemie finansowym który zakopie twoją firmę,
czy zapłacić więcej za lepszego programistę ? ;)
Kazimierz Pogoda
> takie sławy programistyczne jak K. Beck czy M. Fowler mówią że używają
> testów jednostkowych by zwiększyć swoją efektywność (programiści
> czytają: by być bardziej za~!@#stymi programistami, managerowie: by
> więcej pracy o lepszej jakości było wykonane w tym samym czasie), z
> moich obserwacji wynika, iż kto nie spróbował twierdzi że są zbyt
> kosztowne, kto spróbował używa bez względu czy jego PM o tym wie czy
> nie
Chciałbym nieco rozwinąć Twoją myśl: :)
Tak się czasem zastanawiam, czy pojęcie "unit testing" nie jest trochę
źle dobrane - nieco mylące. Elementem metodyki XP jest zalecenie
tworzenia testu jednostkowego przed napisaniem kodu implementacji.
Uzasadnienie jest takie, że programista (programiści w XP) określają
przypadki użycia metod ewaluując przy okazji ich optymalne API. Testy
jednostkowe widziane z tej perspektywy to sposób na dokumentację
specyficznych "use cases" (gdzie programista jest po prostu
użytkownikiem API), czy ogólnie wymagań projektowych.
Do czego zmierzam? - skupiamy się tutaj na testach jednostkowych w
kontekście QA, które zasadniczo następuje jako późny etap w procesie
produkcji oprogramowania. Osobiście w kontekście unit testing
traktował bym QA jako "efekt uboczny", mający sens gdy sprawdza się
pokrycie kodu testami, oraz potem w ewolucji projektu, gdy testy
wykazują regressions. A ja chciałbym położyć nacisk na rolę testu
jednostkowego jako "mentalnego narzędzia" do projektowania API - to o
czym piszę wyżej.
Mamy taką zaprzyjaźnioną firmę w Danii, gdzie obficie czerpie się z
metodyk Agile, i w związku z tym programiści z zasady nie tworzą
javadocs :). Żeby dać przy tym obraz stopnia wykorzystania wzorców
projektowych w ich kodzie, przytoczę anegdotę - każde użycie przez
programistę IFa karane jest pieniężnie (jedna korona, czy coś takiego)
:) . Kiedy dostałem ich kody źródłowe i zapytałem o dokumentację, to
usłyszałem - "dobry kod jest samo-dokumentujący - jeśli coś jest
niejasne to zajrzyj do testów". I faktycznie coraz częściej jest tak,
że kiedy gadam z autorem jakiegoś projektu, który przy braku
dokumentacji usiłuje mi wyjaśnić co i jak, to słyszę "zajrzyj do
testów". :)
Pozdrawiam
Piotr Paradziński
Podpisuję się pod wszystkim ... ale mam swoje (naiwne?) obawy.
> programiści z zasady nie tworzą
> javadocs :)
> (...)
> "dobry kod jest samo-dokumentujący - jeśli coś jest
> niejasne to zajrzyj do testów"
Bardzo boję się takiego podejścia. Mówi się o tym też w kontekście
dobrze napisanego kodu obiektowego. W obu przypadkach mam wrażanie że
nie czuję słodkiego zapachu. Całkowita rezygnacja z pisania komentarzy
(dokumentujących) to podejście bardzo ekstremalne. Nie jestem wielkim
fanem terroryzmu.
Miło jest jak autouzupełnianie pokazuje Ci opis API i nie musisz przy
każdej metodzie szukać testów, które pisałeś n-czasu temu albo ...
... które pisał kolega
... w drugim końcu polski
... który odszedł z firmy
... nie do końca w miłej atmosferze
... a ty masz tylko skompilowaną bibliotekę bez źródeł.
Nierealne? Mi się zdarzyło.
Do tego ta cała masa kodu, będącego efektem ciągłych zmian wymagań i
takiej presji terminów że się biega z pustymi taczkami bo nie ma
czasu ich załadować.
... napisana przez programistę C
... z nawykiem nieustannej optymalizacji kodu na poziomie bitów
... sama aplikacja w Java
... albo w języku jednokrotnego zapisu typu Perl.
Też się zdarza.
OTOH pair programming też budził we mnie opór. A jego efektem ubocznym
też jest wczesne (czytaj szybkie==tańsze) wykrywanie błędów ergo
korzyści przy QA.
Pozdrawiam
--
Piotr Paradziński
Pawel Debski
> Tak się czasem zastanawiam, czy pojęcie "unit testing" nie jest trochę
> źle dobrane - nieco mylące. Elementem metodyki XP jest zalecenie
> tworzenia testu jednostkowego przed napisaniem kodu implementacji.
> Uzasadnienie jest takie, że programista (programiści w XP) określają
> przypadki użycia metod ewaluując przy okazji ich optymalne API. Testy
> jednostkowe widziane z tej perspektywy to sposób na dokumentację
> specyficznych "use cases" (gdzie programista jest po prostu
> użytkownikiem API), czy ogólnie wymagań projektowych.
>
> Do czego zmierzam? - skupiamy się tutaj na testach jednostkowych w
> kontekście QA, które zasadniczo następuje jako późny etap w procesie
> produkcji oprogramowania. Osobiście w kontekście unit testing
> traktował bym QA jako "efekt uboczny", mający sens gdy sprawdza się
Gratuluję przenikliwości i jasnego formułowania poglądów.
Nie zgodziłbym się natomiast z poglądem, że QA ma (powinno mieć?)
miejsce na późnym etapie projektu.
Prof. Turski, którego uważam za swojego mistrza, mawiał że dodanie QA na
koniec projektu, to tak jakby robić brudne jedzenie, a następnie dać
silną dawkę promieniowania, żeby wybić zarazki.
Czy o taki efekt chodzi?
> (offtopic) Odnośnie płacy - wolisz zapłacić programiście mniej
> pieniędzy i mieć błąd w systemie finansowym który zakopie twoją firmę,
> czy zapłacić więcej za lepszego programistę ? ;)
Widzę też, że włożyłem kij w mrowisko wspominając o pieniądzach.
Proponuję żeby zamiast się wyzłośliwiać rozważyć ważny w tym kontekście
aspekt:
- w latach 90tych wystarczyło zarzucić projekt ludźmi, żeby coś
(niekoniecznie sensownego) powstało w terminie.
- w chwili obecnej trzeba uważnie żonglować osobodniami w 3-4
kategoriach kosztowych, a prawidłowa metodyka działania jest znacznie
bardziej istotna.
W szczególności nie ma czasu ani pieniędzy na poprawianie po partaczach.
>
> to jakby ktoś się zapędził w ufaniu testom ;]
>
No właśnie. Zbytnia pewność siebie już niejednego zgubiła.
Ostatecznie zawsze czynnikiem decydującym ludzie - albo robią dobrą
robotę, albo nie.
Nie ma to jak zapładniająca dyskusja przed snem ;-)
Czym, życzę wszystkim dobranoc...
Kazimierz Pogoda
>> traktował bym QA jako "efekt uboczny",
> Nietrywialny efekt uboczny :) Nieprawdaż?
Oj prawdaż, prawdaż. :)
>> programiści z zasady nie tworzą
>> javadocs :)
>> (...)
>> "dobry kod jest samo-dokumentujący - jeśli coś jest
>> niejasne to zajrzyj do testów"
>
> Bardzo boję się takiego podejścia. Mówi się o tym też w kontekście
> dobrze napisanego kodu obiektowego. W obu przypadkach mam wrażanie że
> nie czuję słodkiego zapachu. Całkowita rezygnacja z pisania komentarzy
> (dokumentujących) to podejście bardzo ekstremalne. Nie jestem wielkim
> fanem terroryzmu.
Nie pisałem o naszej firmie, tylko o zaprzyjaźnionej. :) Osobiście
nawet przesadzam z javadocami. Przy moim perfekcjonizmie czuję się
dobrze udokumentowawszy wszystko powyżej metod i pól prywatnych, a i
dla "private" często czynię wyjątki. Dobry przykład gdzie javadocs to
konieczność - nawet jeśli parametry i nazwy metod są
"samodokumentujące", to w przypadku metody rzucających
RuntimeException (np. NumberFormatException), nie opisanie tego
javadociem może mieć opłakane skutki.
Kazimierz Pogoda
> Nie zgodziłbym się natomiast z poglądem, że QA ma (powinno mieć?)
> miejsce na późnym etapie projektu.
Wynika z tego że jednak nie wyraziłem się do końca jasno :( Powinienem
był inaczej to ująć.
Miałem na myśli logiczną sekwencję:
1. zbieranie wymagań -> 2. projektowanie -> 3. implementacja -> 4.
zapewnienie jakości -> 5. wdrożenie
Oczywiście taki cykl w typowych projektach (szczególnie przy
metodykach Agile i podejściu iteracyjnym), ma wysoki stopień
"sprzężenia zwrotnego" - prac z reguły nie wykonuje się czysto według
takiej sekwencji. Z tego względu też oczywiście uważam, że
infrastrukturę dla realizacji wszystkich elementów (z QA w
szczególności) warto zapewnić o ile to możliwe jeszcze przed
rozpoczęciem projektu. Mi chodziło tylko o to, żeby o testach
jednostkowych więcej myśleć w kontekście 2., albo nawet 1., a nie
wyłącznie 4. + ewentualnie 3.
pikson
On 2008-06-24, at 00:00, Kazimierz Pogoda wrote:
> 2008/6/23 Pawel Debski <pde...@econsulting.pl>:
>> Nie zgodziłbym się natomiast z poglądem, że QA ma (powinno mieć?)
>> miejsce na późnym etapie projektu.
>
> Wynika z tego że jednak nie wyraziłem się do końca jasno :( Powinienem
> był inaczej to ująć.
>
> Miałem na myśli logiczną sekwencję:
>
> 1. zbieranie wymagań -> 2. projektowanie -> 3. implementacja -> 4.
> zapewnienie jakości -> 5. wdrożenie
>
> Oczywiście taki cykl w typowych projektach (szczególnie przy
> metodykach Agile i podejściu iteracyjnym), ma wysoki stopień
> "sprzężenia zwrotnego" - prac z reguły nie wykonuje się czysto według
> takiej sekwencji. Z tego względu też oczywiście uważam, że
> infrastrukturę dla realizacji wszystkich elementów (z QA w
> szczególności) warto zapewnić o ile to możliwe jeszcze przed
> rozpoczęciem projektu. Mi chodziło tylko o to, żeby o testach
> jednostkowych więcej myśleć w kontekście 2., albo nawet 1., a nie
> wyłącznie 4. + ewentualnie 3.
>
A ja mam wrażenie, że jak piszecie o testach unitowych, to każdy
myśli o czymś innym.
Czy testy funkcjonalne, integracyjne, unitowe itd. nie są
wystarczającym rozróżnieniem?
Nie bardzo rozumiem czemu testy unitowe w ogóle łączy się z QA'mi?
Czy testy unitowe nie są związane z małymi kawałeczkami kodu, które
są testowane przez programistów?
Wydaje mi się, że pojęcie testu unitowego powinno być jakoś
usystematyzowane, bo dla mnie to jakieś dziwne zamieszanie myśleć o
jednym rodzaju testu w kilku kontekstach.
Pozdrawiam
Tomasz Trela
Kazimierz Pogoda
> A ja mam wrażenie, że jak piszecie o testach unitowych, to każdy
> myśli o czymś innym.
Właśnie na to wygląda i to jest dosyć interesujące. :)
> Czy testy funkcjonalne, integracyjne, unitowe itd. nie są
> wystarczającym rozróżnieniem?
Mi chodzi nie o to "co jest czym?", bo "test jednostkowy" zawsze w
kategoriach "co?" pozostanie testem "kawałka kodu". Nie chodzi mi też
o to "jak?, jak to zrobić?" - czy junit, czy TestNG, czy dbunit, czy
cactus, etc. Chodzi mi o "dlaczego?" - zasadniczą funkcję testu - cel
dla którego test piszemy. A tu podejście jest jak widać niejedno.
> Nie bardzo rozumiem czemu testy unitowe w ogóle łączy się z QA'mi?
Ja bym łączył to przede wszystkim w kategoriach statystyk code
coverage testów, obok statycznej analizy kodu.
> Czy testy unitowe nie są związane z małymi kawałeczkami kodu, które
> są testowane przez programistów?
Zdecydowanie, ale programiści (przynajmniej Javy i ogólnie języków
obiektowych) nie tyle piszą sekwencje instrukcji reprezentujące
algorytm, co określają sposób zachowania obiektów w reakcji na
wywołania ich metod. To są dwa różne aspekty tej samej pracy, ale
skupienie się przy pisaniu testów jednostkowych na tym pierwszym
byłoby świadectwem kompletnego niezrozumienia zagadnienia.
Kiedy mam do zaprojektowania API jakiejś biblioteki, to zaczynam od
pisania testu i taki sposób kodowania promuję w firmie. Test
jednostkowy powstaje wtedy przed implementacją. Czy jego istnienie ma
jakikolwiek sens bez implementacji? Z pozoru nie, ale przecież
implementację możemy całkowicie zmienić. Dlatego tak ciekawe są
abstrakcyjne testy jednostkowe - np. te z commons-collections, albo
sunowski Java Test Compatibility Kit.
Każdy odpowiednio skomplikowany system zaczyna z czasem przejawiać
własności nieredukowalne do własności jego elementów składowych. Np. w
firmie napisaliśmy nowy język programowania zaimplementowany w Javie.
Mamy sporo testów jednostkowych na poziomie kodu Javy - część z nich
napisana przed implementacją, teraz z kolei myślimy o testach
jednostkowych dla kolejnego poziomu abstrakcji - naszego języka.
Gdybyśmy mieli odpowiednio dużo doświadczenia i jeszcze więcej
wyobraźni :) kiedy zaczynaliśmy parę lat temu projekt, to zaczęlibyśmy
właśnie od tych bardzo abstrakcyjnych testów - po to by dokładnie
wiedzieć co potem zaimplementować.
Grzegorz Duda
przeciwnikiem testow, czy samego TDD, ale chcialem Wam zadac kilka
pytan (do samodzielnego przemyslenia, lub podzielenia sie swoja opinia
tutaj):
- czy statystyki code coverage cokolwiek nam mowia? Czy aby 100% to
nie jest wciaz za malo, zeby byc "w miare" pewnym poprawnosci
dzialania kodu? A z drugiej strony po co testy do trywialnych metod
(strata czasu aby miec 100%?).
- czy pisanie testow nie odciaga uwagi od samej implementacji? A
implementacja jest sprowadzana do zaspokojenia testow, a nie
rozwiazania wlasciwego/pierwotnego problemu.
- czy jakosc testow nie jest uzalezniona od jakosci programisty, a
wiec takze i od wlasciwej implementacji (dobra implementacja - po co
wiec testy, zla implementacja - testy i tak do kitu).
- czy aby na pewno ilosc czasu spedzona przy pisaniu testow jest
mniejsza od ilosci czasu spedzonego na debugowaniu?
- czy nie bardziej "oplacalne" jest zainwestowanie tego czasu w pair
programming, dobre code review itp?
- czy TDD to nie kolejny buzz word. ktory trzeba wpisac w CV, zeby dostac prace?
- ile osob wlasciwie stosuje TDD? (chyba dr. Kabutz, a moze ktos inny,
zadal to pytanie na jakiejs konferencji Javowej i tylko kilka procent
osob podnioslo reke), czy wiec TDD rzeczywiscie odroznia dobrego
programiste od zlego?
Jaka jest wiec Wasza opinia?
Regards,
Grzegorz Duda (http://grzegorzduda.blogspot.com)
Polish JUG (http://java.pl)
2008/6/24 Kazimierz Pogoda <hsh...@gmail.com>:
> 2008/6/24 pikson <pikso...@gmail.com>:
Adrian Nowak
wytrzymalem ;) Zdecydowanie czas na pisanie testow zwraca sie z nawiazka
w porownaniu z debugowaniem. Przynajmniej takie sa moje odczucia, kiedy
zaczalem uzywac ~TDD nie moglem juz wrocic do programowania bez
automatycznych testow, bo bylo to duzo! bardziej meczace. Po kazdej
zmianie w aplikacji nie moglem przewidziec co sie "popsulo".
Do tego nie wszystko daje sie zdebugowac (np. system wielowatkowy), a
testami mozna sobie przynajmniej probowac pomoc utrzymać pewne sytuacje
poprawne (przy maagisterce wystarczy).
Przy pozostalych pytaniach pewnie kazdy bedzie mial watpliwosci. Pytanie
tez czy pytajac kto stosuje TDD pytamy o to czy pisze test najpierw czy
powiedzmy rownolegle (np. na poziomie kolejnych metod). To drugie jest
jakby takie bardziej agile ;)
Pozdrawiam,
Adrian
--
Pozdrawiam,
Adrian Nowak
Polish Java User Group
www.java.pl
Radoslaw H. Urbas
No to jeszcze moj kij do mrowiska. Na wstepie zaznaczam, ze nie jestem
przeciwnikiem testow, czy samego TDD, ale chcialem Wam zadac kilka
pytan (do samodzielnego przemyslenia, lub podzielenia sie swoja opinia
tutaj):
- czy statystyki code coverage cokolwiek nam mowia? Czy aby 100% to
nie jest wciaz za malo, zeby byc "w miare" pewnym poprawnosci
dzialania kodu? A z drugiej strony po co testy do trywialnych metod
(strata czasu aby miec 100%?).
Zakladajac, ze ktos nie pisze celow testow tak zeby byl coverege wysoki, a nic nie robily (czyli np 0 assertow) to coverege mowi sporo - widac np czy sa jakies sciezki w programie do ktorych test (a zatem pewnie i jakiekolwiek uruchomienie) nigdy nie dotarly.
- czy pisanie testow nie odciaga uwagi od samej implementacji? A
implementacja jest sprowadzana do zaspokojenia testow, a nie
rozwiazania wlasciwego/pierwotnego problemu.
Jesli ktos uprawia prawdziwe TDD - to implementacja sprowadza sie do spowodowania aby testy sie a) kompilowaly b) przechodzily.
Programowanie powinno byc nudne.
- czy jakosc testow nie jest uzalezniona od jakosci programisty, a
wiec takze i od wlasciwej implementacji (dobra implementacja - po co
wiec testy, zla implementacja - testy i tak do kitu).
Jak najbardziej. Jakosc testow w 90% zalezy od jakosci programisty. I zaden automagiczny tool do generowanie testow nigdy nie zastapi nawet przecietnego programisty ;-) ;-)
- czy aby na pewno ilosc czasu spedzona przy pisaniu testow jest
mniejsza od ilosci czasu spedzonego na debugowaniu?
Z mojego doswiadczenie tak, w szczegolnosci jak ktos inny po jakims czasie jakies zmiany robi w kodzie...
- czy nie bardziej "oplacalne" jest zainwestowanie tego czasu w pair
programming, dobre code review itp?
Do pair programming trzeba miec warunki lokalowe odpowiednie ;-)
- czy TDD to nie kolejny buzz word. ktory trzeba wpisac w CV, zeby dostac prace?
- ile osob wlasciwie stosuje TDD? (chyba dr. Kabutz, a moze ktos inny,
zadal to pytanie na jakiejs konferencji Javowej i tylko kilka procent
osob podnioslo reke), czy wiec TDD rzeczywiscie odroznia dobrego
programiste od zlego?
TDD odroznia programiste leniwego od mniej leniwego. Po co sie analizowac kod, jak mozna po prostu sprawdzic czy dziala ?! (nie zeby od tego nastepnym krokiem bylo automatyczne generowanie kodu...)
Jaka jest wiec Wasza opinia?
To tyle ;-)
Regards,
Grzegorz Duda (http://grzegorzduda.blogspot.com)
Polish JUG (http://java.pl)
2008/6/24 Kazimierz Pogoda <hsh...@gmail.com>:
> 2008/6/24 pikson <pikso...@gmail.com>:
>> Nie bardzo rozumiem czemu testy unitowe w ogóle łączy się z QA'mi?
>
> Ja bym łączył to przede wszystkim w kategoriach statystyk code
> coverage testów, obok statycznej analizy kodu.
>
Radoslaw H. Urbas
- testy zostaja: dla Ciebie do odpalenia za 2 dni, za pol roku, dla jakiegokolwiek innego programisty ktory bedzie sie tym kiedys jeszcze zajmowal
- debuggowanie - wiesz w momencie debuggowania co sie dzieje, moze jeszcze za tydzien pamietasz co sie dzialo ;-)
Robert Sajdok
On 23 Cze, 22:13, "Kazimierz Pogoda" <hsh...@gmail.com> wrote:
> 2008/6/23 Piotr Paradziński <piotr.paradzin...@gmail.com>:
> > takie sławy programistyczne jak K. Beck czy M. Fowler mówią że używają
> > testów jednostkowych by zwiększyć swoją efektywność (programiści
> > czytają: by być bardziej za~!@#stymi programistami, managerowie: by
> > więcej pracy o lepszej jakości było wykonane w tym samym czasie), z
> > moich obserwacji wynika, iż kto nie spróbował twierdzi że są zbyt
> > kosztowne, kto spróbował używa bez względu czy jego PM o tym wie czy
> > nie
>
> Chciałbym nieco rozwinąć Twoją myśl: :)
>
> Tak się czasem zastanawiam, czy pojęcie "unit testing" nie jest trochę
> źle dobrane - nieco mylące. Elementem metodyki XP jest zalecenie
> tworzenia testu jednostkowego przed napisaniem kodu implementacji.
równocześnie ? Tak przynajmniej ja to wyczytałem i bardziej to do mnie
przemawia.
--
Robert Sajdok (Ris)
Kazimierz Pogoda
> - czy statystyki code coverage cokolwiek nam mowia? Czy aby 100% to
> nie jest wciaz za malo, zeby byc "w miare" pewnym poprawnosci
> dzialania kodu? A z drugiej strony po co testy do trywialnych metod
> (strata czasu aby miec 100%?).
Jeśli chodzi o code coverage to dla mnie osobiście mniej użyteczne są
statystyki, a bardziej "zapalone na czerwono" fragmenty kodu w IDE,
czy w raportach. Warto przyjrzeć się dokładnie właśnie tym miejscom.
> - czy pisanie testow nie odciaga uwagi od samej implementacji? A
> implementacja jest sprowadzana do zaspokojenia testow, a nie
> rozwiazania wlasciwego/pierwotnego problemu.
Dobre pytanie. Wyobrażam sobie, że może tak być. Ale czy pierwotny
problem nie leży wtedy w nieodpowiednio napisanym teście?
> - czy jakosc testow nie jest uzalezniona od jakosci programisty, a
> wiec takze i od wlasciwej implementacji (dobra implementacja - po co
> wiec testy, zla implementacja - testy i tak do kitu).
Kryterium "jakości programisty" to kategoria słabo definiowalna.
Zakładam, że można napisać poprawny kod implementacji bez stosowania
testów jednostkowych. Ja jednak traktuję testy przede wszystkim jako
protezę dla pokrycia własnych ograniczeń i braku wyobraźni. Często
rezygnuję z pisania testów dla komponentów GUI - to można zobaczyć i
wyklikać. Testy dla kontroli efektów działania servletów - też bym się
zastanawiał. Dla prostych beanów z mutators/accessors też nie bardzo
jest sens. Jest jednak wiele kategorii kodu, gdzie nie da się po
prostu wywołać main()/wpisać URL w przeglądarce i zobaczyć jak to
działa. Przynajmniej takie są nasze projekty - kod czysto serwerowy,
ale nie servletowy. Jeśli w ogóle chcemy kodować inaczej niż "na
sucho", zanim komponenty trafią do skomplikowanego kontenera, to
potrzebujemy testu chociażby jako "entry point" by uruchomić
debugowanie. Dlatego tak bardzo propaguję podejście, że w przypadku
testów jednostkowych testowanie kodu to "efekt uboczny". Pierwszy cel
to w ogóle dostać się do kodu, jeśli nie można wizualizować efektów
jego działania. A jakość samych testów to już osobne zagadnienie.
> - czy aby na pewno ilosc czasu spedzona przy pisaniu testow jest
> mniejsza od ilosci czasu spedzonego na debugowaniu?
O tym wyżej :)
> - ile osob wlasciwie stosuje TDD? (chyba dr. Kabutz, a moze ktos inny,
> zadal to pytanie na jakiejs konferencji Javowej i tylko kilka procent
> osob podnioslo reke), czy wiec TDD rzeczywiscie odroznia dobrego
> programiste od zlego?
"Dobry programista" - znowu kategoria słabo określona :) . W naszych
czasach, w branży IT, "dobry programista", to "pragmatyczny
programista". Ale to się ma raczej nijak do kontekstu akademickiego.
Nie podchodził bym do TDD wyznaniowo - jeśli pomaga w realizacji celów
- warto stosować, jeśli nie, warto porzucić.
Jeśli tworzymy projekt na zaliczenie - wykładowca raczej nie zajrzy do
testów (chyba że to jest przedmiotem zaliczenia - ciekawe czy na
którejś uczelni w Polsce coś takiego się zdarza :) ). Jeśli tworzymy
jednorazowy projekt na zamówienie, który nie będzie później
konserwowany, testy jednostkowe mogą stanowić zbyt duży overhead.
Jeśli tworzymy kod biblioteki - np. takiej która manipuluje stringami,
albo do operacji matematycznych - np. obróbki danych statystycznych -
w takim przypadku testy jawią mi się jako konieczność.
Specyfika kodu naszych firmowych projektów jest mniej więcej taka:
- biblioteki 3rd party (jakarta commons, jgraph, etc. - zasadniczo Open Source)
- biblioteki własne (utils, rmi, collections, ioc, crypt, etc.)
- właściwy kod projektu
Jeśli chodzi o pokrycie testami, to najbardziej zależy mi na kategorii
"biblioteki własne" - resztę traktuję już po macoszemu :)
Radoslaw H. Urbas
Jeśli tworzymy projekt na zaliczenie - wykładowca raczej nie zajrzy do
testów (chyba że to jest przedmiotem zaliczenia - ciekawe czy na
którejś uczelni w Polsce coś takiego się zdarza :) ).
Na AGH - zdarzalo mi sie to ;-)
Pozdrawiam,
Kazimierz Pogoda
>> Tak się czasem zastanawiam, czy pojęcie "unit testing" nie jest trochę
>> źle dobrane - nieco mylące. Elementem metodyki XP jest zalecenie
>> tworzenia testu jednostkowego przed napisaniem kodu implementacji.
> A czasem nie jest zalecane pisanie testów i implementacji
> równocześnie ? Tak przynajmniej ja to wyczytałem i bardziej to do mnie
> przemawia.
Z wikipedii:
http://en.wikipedia.org/wiki/Test-driven_development
"Practitioners emphasize that test-driven development is a method of
designing software, not merely a method of testing."
I bardzo podoba mi się jeszcze:
"Fake it, till you make it"
:) Dzisiaj wypróbowywałem mockito - to była duża przyjemność. :)
Wiktor Gworek
2008/6/24 Robert Sajdok <r...@onet.pl>:
>> Tak się czasem zastanawiam, czy pojęcie "unit testing" nie jest trochęZ wikipedii:
>> źle dobrane - nieco mylące. Elementem metodyki XP jest zalecenie
>> tworzenia testu jednostkowego przed napisaniem kodu implementacji.
> A czasem nie jest zalecane pisanie testów i implementacji
> równocześnie ? Tak przynajmniej ja to wyczytałem i bardziej to do mnie
> przemawia.
http://en.wikipedia.org/wiki/Test-driven_development
"Practitioners emphasize that test-driven development is a method of
designing software, not merely a method of testing."
I bardzo podoba mi się jeszcze:
"Fake it, till you make it"
:) Dzisiaj wypróbowywałem mockito - to była duża przyjemność. :)
Przyglądałem się tej dyskusji, czas dorzucić swoje trzy grosze. Coś mi się zdaje, że TDD to kolejny nadużywany buzzword (chociaż z deka już trochę przestarzały, bo BDD rozpycha się łokciami). Uważam, że ktoś, kto stosuje TDD, ma przeczytaną książkę Kenta Becka. Nikt nigdzie a propos TDD tego nie powiedział: o robieniu małych kroczków lub jeśli wolimy robić większe to o możliwości w każdej chwili zwolnienia developmentu i robieniu małych kroczków. Nie wspominając o mantrze TDD :). Idzmy dalej.
Jak pisać testy? Przed, równocześnie (to akurat trzeba wykreślić, bo co ma znaczyć równoległe pisanie testów?), po... no własnie - jest dużo możliwości. Zgodznie z TDD testy pisane są przed napisaniem kodu. Kropka. Wszystko inne to co najwyżej podejście zarażone testowanie (ang. test-infected). Joshua Bloch w prezentacji "How to design a good API?" mówi wprost: na początku wejdźciew rolę użytkownika API i zacznijcie się nim posługiwać, a później dopiero piszcie implementację. Całkowicie się z nim zgadzam, interfejsy najpierw a później implementacja. Zauważcie, że jest to zgodne z podejściem TDD. Zwiększamy jakość kodu, czyli to o co nam chodzi. Chyba każdy z nas napisał klasę, której używanie było strasznie toporne :).
Język. Ponieważ większość z nas to Javowcy to sami wiemy, jak TDD jest na początku trudne. IDE wyświetla ciągle błedy np. brak metody, ale można się do tego przyzwyczaić. W językach dynamicznych wygląda to znacznie lepiej, bo dynamiczne typowanie opóźnia nam powiadomienie o błędzie i możemy skoncentrować się na pisaniu testu (oczywiście miecz ma dwa końce...).
Automatyzacja. Od jakiegoś czasu bardziej poświęcam się web-developmentowi i na codzień używam do webu Ruby on Rails (ktoś w końcu musiał to zaklęcie wypowiedzieć ;)). TDD jest w środowisku railsowym bardzo popularne, gdyż testy dają większe poczucie bezpieczeństwa - konsekwencja dynamicznego typowania. Przytoczę tutaj jedno narzędzie: autotest z pakietu ZenTest. Co to robi? Otóż obeserwuje katalog z testami i z kodem źródłowym. Gdy nastąpi zmiana w teście lub np. kodzie kontrollera, czy modelu to uruchamia on od razu odpowiednie testy. Tak :), jeśli zmienię coś w JugController to zostanie od razu odpalony test dla niego :). Notyfikacja o powodzeniu czy niepowodzeniu wyświetlana jest dodatkowo obok konsolki jako notyfikacja systemowa. Odpalanie testów z poziomu IDE jakoś nie pasjonowało mnie i uważam to za stratę czasu, są inne lepsze narzędzia.
Baza danych. Izolacja. Nie widziałem w Javie żadnego frameworka (proszę mnie poprawić, jeśli się mylę), który pozwalałby na izolację testów z BD testową. Oczywiście można sobie mockować modele, czy DAO, ale jest to pracochłonne. Frameworki, które przewidują od razu środowisko testowe, produkcyjne, developerskie, będą częście wybierane przez developerów. Dlatego nie dziwi mnie popularność Springa :).
No to dorzuciłem swoje trzy grosze.
Wiktor
http://blog.mocna-kawa.com
Bartosz Bańkowski
> początku trudne. IDE wyświetla ciągle błedy np. brak metody, ale można się
> do tego przyzwyczaić. W językach dynamicznych wygląda to znacznie lepiej, bo
> dynamiczne typowanie opóźnia nam powiadomienie o błędzie i możemy
> skoncentrować się na pisaniu testu (oczywiście miecz ma dwa końce...).
Dobrze, że dopisałeś to w nawiasie. Dla mnie jest wręcz przeciwnie.
To, że IDE pokazuje mi błędy, jest jak najbardziej właściwe. Jeśli
używasz Eclipse'a, to dzięki opcji Quick Fix te wszystkie klasy i
metody zrobi za Ciebie IDE. A tego zdecydowanie brakuje mi, gdy np.
programuje w Rubym.
Pozdrawiam,
Bartosz Bańkowski
ags
- czy statystyki code coverage cokolwiek nam mowia? Czy aby 100% to
nie jest wciaz za malo, zeby byc "w miare" pewnym poprawnosci
dzialania kodu? A z drugiej strony po co testy do trywialnych metod
(strata czasu aby miec 100%?).
1.: Niektórzy kochają i naprawdę *muszą* mieć mierniki, a lepsze liczenie coverage'u niż LOC. Można zrobić wykres i go pokazywać, cieszyć się jak jest stromo w gorę i objeżdżać jak jest płasko lub w dół.
2.: Dzięki liczeniu statystyk można odkryć, że istnieje metoda z >400 ścieżkami przejścia i nikt do końca nie wie jak ona działa. Lub, że cały kod jest doskonalą implementacją Węzła Gordyjskiego.
3. Mnie osobiście do szczęscia nie są konieczne.
4. % to mylący miernik, bo każdy chciałby mieć 100, mimo że to ani konieczne ani sensowne.
- czy pisanie testow nie odciaga uwagi od samej implementacji? A
implementacja jest sprowadzana do zaspokojenia testow, a nie
rozwiazania wlasciwego/pierwotnego problemu.
- czy jakosc testow nie jest uzalezniona od jakosci programisty, a
wiec takze i od wlasciwej implementacji (dobra implementacja - po co
wiec testy, zla implementacja - testy i tak do kitu).
Zacznijmy od odwracania uwagi: zależy od co chce dana osoba/zespół osiągnąć. Jeżeli ktoś się uprze i za wszelką cenę będzie chciał otestować każdą linijkę na 10. stronę, to to zrobi. Nie bedzie to mial wiele wspólnego ze zdrowym rozsądkiem.
Jakość testów jest oczywiscie zależna od jakości programistów. Kod piszą ludzie, w przeważającej części 'zwykli' - rozkład normalny jest nieubłagany. Zmiana punktu widzenia (implementacja <-> testy) pomaga spojrzeć z innej strony na tworzony kod/problem i *może* pomóc znaleźć dziury we własnym toku myslenia.
Dla mnie najcenniejsze w pisaniu testów jest to, ze mogę poużuywać sobie tego, co dopiero mam napisac. IDE jest tutaj pomocne, bo samo wypluje mi pod to klasy z metodami.
- czy aby na pewno ilosc czasu spedzona przy pisaniu testow jest
mniejsza od ilosci czasu spedzonego na debugowaniu?
Zależy :) Lepiej wcześniej znaleźć problem niż później. Do tego patrząc z punktu widzenia, w którym grozi regularne czekanie po kilka minut na wstanie serwera z aplikacją, zrobienie sobie zestawu mocków i testowanie na sucho jest warte zachodu.
- czy nie bardziej "oplacalne" jest zainwestowanie tego czasu w pair
programming, dobre code review itp?
Wszystkie są środkami na drodze do osiągnięcia pewnego celu. Nie sądzę, że da się je porównać ani przeliczyć na zasadzie 2tdd za 1 code review. Żadne nie jest 'silver bullet', żadne niczego nie gwarantuje. Oczywiście, każda pliszka swój ogon chwali, jedni jeżdżą po świecie i promują a, drudzy b, a trzeci TDD.
- czy TDD to nie kolejny buzz word. ktory trzeba wpisac w CV, zeby dostac prace?
- ile osob wlasciwie stosuje TDD? (chyba dr. Kabutz, a moze ktos inny,
zadal to pytanie na jakiejs konferencji Javowej i tylko kilka procent
osob podnioslo reke), czy wiec TDD rzeczywiscie odroznia dobrego
programiste od zlego?
To takie moje 3 grosze.
Kazimierz Pogoda
> ... Joshua Bloch w prezentacji "How to design a good API?" mówi
> wprost: na początku wejdźciew rolę użytkownika API i zacznijcie się nim
> posługiwać, a później dopiero piszcie implementację. Całkowicie się z nim
> zgadzam, interfejsy najpierw a później implementacja. Zauważcie, że jest to
> zgodne z podejściem TDD. Zwiększamy jakość kodu, czyli to o co nam chodzi.
> Chyba każdy z nas napisał klasę, której używanie było strasznie toporne :).
O ile pamiętam w którymś wywiadzie Gosling opowiedział nieco
żartobliwie, że największy błąd jaki popełnił podczas projektowania
Javy to dopuszczenie do istnienia klas - powinny być same interfejsy.
:)
> Język. Ponieważ większość z nas to Javowcy to sami wiemy, jak TDD jest na
> początku trudne. IDE wyświetla ciągle błedy np. brak metody, ale można się
> do tego przyzwyczaić.
Hmm, w eclipse w takich sytuacjach robię CTRL-1 (o przepraszam -
jabłko-1 ;) ) i Enter.
Adrian Nowak
> 2008/6/25 Kazimierz Pogoda <hsh...@gmail.com <mailto:hsh...@gmail.com>>:
razie mi sie to zdarzylo i mozna to czasami uzasadnic. Byl to bowiem
system z kawalkiem obejmujacym cos ala parserem html'a tyle ze
oczywiscie wyczulony na pewne oznaczenia (uuu w 2001 jeszcze, akronimu
TDD chyba nie bylo, a ja mialem szczescie wejsc w ciekawy projekt). W
kazdym razie nie do konca wyobrazam sobie napisania najpierw testow dla
takiego parsera i wylapania wszystkich podejrzanych konstrukcji
(wlaczjac niepoprawne skladniowo kawalki html, ktore mialy rowniez
"przechodzic").
Byc moze tez sa sytuacje ze posiadanie pewlnego zestawu testow przed
implementacja powodowac moze trudnosci w postepach nad implementacja ...
no dobra bronie sie troche ;)
Na pewno testy pisane kiedykolwiek sa duzo lepsze niz ich brak, a
niestety pozniej nie mialem tyle szczescia i mojego szefa nie udalo sie
przekonac do "straty czasu na pisanie testow"... dzieki temu mam uraz do
recznego debugowania na cale (krotkie) zycie (i softwaru produkcji
szczesciarzy dzisiejszych rozgrywek, choc to pewnie mi przejdzie pszy
lepszej okazji).
Pozdrawiam,
Adrian
Bartosz Bańkowski
> razie mi sie to zdarzylo i mozna to czasami uzasadnic. Byl to bowiem
> system z kawalkiem obejmujacym cos ala parserem html'a tyle ze
> oczywiscie wyczulony na pewne oznaczenia (uuu w 2001 jeszcze, akronimu
> TDD chyba nie bylo, a ja mialem szczescie wejsc w ciekawy projekt). W
> kazdym razie nie do konca wyobrazam sobie napisania najpierw testow dla
> takiego parsera i wylapania wszystkich podejrzanych konstrukcji
> (wlaczjac niepoprawne skladniowo kawalki html, ktore mialy rowniez
> "przechodzic").
>
> Byc moze tez sa sytuacje ze posiadanie pewlnego zestawu testow przed
> implementacja powodowac moze trudnosci w postepach nad implementacja ...
> nodobra bronie sie troche ;)
Test-first nie oznacza napisania wszystkich możliwych przypadków
testowych. Tworzysz jeden i implementujesz do niego funkcjonalność,
refaktorujesz i tak w kółko. Nie wyobrażam sobie stworzenia całego
zestawu testów przed. Będzie to tak samo nieefektywne, jak napisanie
najpierw kodu, a później testów. To co Ty nazywasz "równoległym"
pisaniem testów, to jest właściwe zastosowanie TDD.
Pozdrawiam,
Bartosz Bańkowski
Adrian Nowak
W takim razie mowiac o TDD (chyba za wszesnie zetknalem sie z praktyka i
przez to teorie tylko liznalem) brakuje precyzji, bo raz podkresla sie
ze testy przed implementacja (co oczywiscie rozumiec mozna jako przed
implementacja metody, a nie calego czy wiekszego fragmentu projektu), a
dwa w pojeciu refaktoryzacji nie miesci sie przeciez zmina/rozszerzenie
dzialania tylko poprawa struktury kodu (funkcjonalnalnosc pozostaje).
Pozdrawiam,
Adrian