Temat: TDD, testowanie i inne takie

Jarek Żeliński:

Krzysztof T.:
Moja żonka (też informatyk) gdy przeczytała tę dyskusję stwierdziła: "I nad czym tu deliberować - przecież cały Agile sprowadza się do tego, by stosowaną metodykę dozbroić w cykliczne interakcje z klientem, a Wy piszecie i piszeeeecie... o czym tu pisać?"

ale jeżeli wiec ktoś ma te metodykę, bez żadnego Agile i tak spotyka się cyklicznie, ale "niestety" kodowanie poprzedza analizą i projektowaniem, to albo czegoś nie rozumiem (tych dyskusji) albo nie wiem, że "od lat pisze prozą" :)

Otóż nie :)
Od strony wykonawcy wygląda to ciut inaczej. Wykonawca, pracując w określonej metodyce (bez Agile) zaczyna swoją pracę od studiów dokumentacji, a kończy na testach odbiorowych (Analiza przychodzi z zewnątrz lub jest wykonywana przez wyodrębniony człon analityczny, Implementacja rusza gdy istnieje juz wymagana do implementacji część dokumentacji). Pomiędzy tymi dwoma elementami nie ma komunikacji z klientem (chyba, że ten jeszcze ma otwarty proces prac przy zbieraniu założeń, ale to są prace nad nieruszonymi jeszcze obszarami). Agile wprowadza tę komunikację dając klientowi możliwość doprecyzowania szczegółów, które z pozycji wykonawcy nie mają zasadniczo wpływu na funkcjonalność (zmiana funkcjonalności to zmiana kontraktu, jest traktowana jako CR).
UWAGA: nie mylić dołożenia flow z klientem z sytuacją, gdy douzupełniane są dokumenty ze względu na wykrycie dziur w kwitach, lub ze względu na prace prowadzone w obszarach future. To zupełnie inna sytuacja. Agile zakłada, że klient dostaje częściowe wypusty produktu, w celu akceptacji cząstkowej i/lub doprecyzowania szczegółów (jak choćby kolejności sortowania na listach rozwijalnych - czego dokumentacja zwykle nie opisuje, a co może mieć znaczenie dla Klienta). Agile oczywiście może i powinno chronić projekt przed produkcją rzeczy na które zapotrzebowanie się zdeaktualizowało - ale to już zupełnie inny temat. Przede wszystkim Agile ma dać klientowi możliwość kontroli postępu prac oraz obciąć koszty kwitologii na duperelach - TYLKO na duperelach.

Faktem jest że rynek notorycznie popełnia dwa grzechy:
1) oszczędza na dokumentacji - w wyniku czego dopłaca na implementacji
2) usiłuje utrącić koszty analizy - w wyniku czego dopłaca na implementacji
Oba te punkty przemycane są pod hasłem Agile - chociaż nie mają z Agile nic wspólnego.

EDIT:
Ty, Jarku, siedzisz w innym obszarze produkcji - i kontakt z Klientem jest z marszu wpisany w Twoje zajęcia :) - po to, aby taki ludek jak ja wiedział, co ma Klientowi wyprodukować. Projekt techniczny też trzeba o coś oprzeć :)Krzysztof T. edytował(a) ten post dnia 12.11.12 o godzinie 11:32

Temat: TDD, testowanie i inne takie

"This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference."

http://en.wikipedia.org/wiki/Test-driven_development

TDD wyróżnia się jedynie tym, że ustala kolejność rzeczy które mogą być robione w dowolnej kolejności.

Na tym polega sedno TDD - na pisaniu testów przed implementacją po to, żeby "programista skupił się na funkcjonalności zanim zacznie ją implementować".

Ja osobiście też znajduję plusy w pisaniu testów przed implementacją - robisz to dokładniej i chętniej niż po.

A co z implementacją? Czy piszę ją dokładniej i chętniej niż przed ? ;)
Test to kod, funkcjonalność to kod ...

W sumie nie widzę nic złego w pisaniu testu przed implementacją; ale jeśli później ktoś (entuzjasta TDD) albo coś (TDD) zaleca "przetestowanie nieistniejącej funkcjonaliści" albo uzasadnia kolejność implementacji "skupieniem się na wymaganiach podczas implementacji testów" to ciężko mi nie odnieść wrażenia, że mam kontakt z wariatem / oszustem / matołkiem.

Oczywiście można zastosować symetryczne podejście - to nie "TDD" jest wariackie (etc ... ) to ja mam wariackie podejście.

Z drugiej strony, kto komu broni uznania za normę przekroczenie terminów, kosztów albo faktu niedostarczenia aplikacji spełniającej wymagania ( agile -i tdd- nie specyfikuje metody definiowania wymagań, wiec ten problem chyba "ich" nie dotyczy).

Dla mnie takie sytuacje są "złe" i świadczą o tym, że "ktoś, coś robi źle".
Dla innych ludzi (często - łącznie z tymi, którzy mają pieniądze) / metodyk są to sytuacje normalne, bo przecież każdy ma jakieś preferencje, świat jest skomplikowany i nie da się -wszystkiego- (niektórzy mylą to z "niczego") przewidzieć.

I jeżeli ja (i spora ilość osób) również znajduje pozytywy w takiej technice, to nie uważam, żeby mógł być to jakikolwiek argument do dyskutowania na temat czyichś kompetencji.

Czy "chęć" i "dokładność" to składowe kompetencji ? ;)
Jak ktoś jest "dokładny" tylko wtedy gdy "mu się chce" to...

Każdy robi tak, aby było jak najlepiej, a że niektórzy wolą pisać testy przed i wg nich przynosi to pozytywne efekty, to dlaczego by mieli robić inaczej?

Bo TDD opisuje taką sytuację. Programista piszący funkcjonalność przed testem nie skupia się dostatecznie na wymaganiach! :D

Może TDD zakłada, że programista nie skupia się na "funkcjonalności" w momencie implementacji,

Skupia się, ale myśli już o tym w inny sposób. Podczas pisania testów starasz się myśleć jak użytkownik, natomiast w trakcie implementacji rozwiązujesz pewien problem.

o rly ?:)

albo że analityk zarabia na błaznowaniu ....

Jeżeli mamy zestaw gotowych scenariuszy użycia, które muszą zostać spełnione, aby funkcjonalność została uznana za poprawną, to w takiej sytuacji rzeczywiście nie ma mowy o jakiejkolwiek wyższości "przed" nad "po" (i odwrotnie:). TDD sprawdza się tam, gdzie testy są tworzone (zestawy danych i scenariusze) przez programistów/testerów.

Jak rozumiem, nie widzisz niczego absurdalnego w sytuacjach, w których jak określiłeś, "sprawdza się TDD"

Interfejs oznacza "stałość". "Nie ważne, co się dzieje w 'bebechach', ważne, że interfejs pozostaje niezmienny".

[...]
Jeśli o mnie chodzi, wystarczy jakaś dobra argumentacja. Powoływanie się na "ekspertów od refaktoringu" nie jest dobrym argumentem na cokolwiek.

Czyli wychodzisz z założenia, że jeżeli masz publiczny interfejs, ale produkt jeszcze nie ujrzał światła dziennego, to nie możesz już tego interfejsu modyfikować, bo ważne, żeby był niezmienny?

Jeśli jego definicję dostarczył mi analityk - to interface jak najbardziej ujrzał światło dziennie.
Jeśli ja projektuję interface - "światło dzienne" go nie ujrzy go do momentu, w którym uznam, że może.

Ja uważam, że niezmienny staje się on dopiero wtedy, gdy pokazujemy go światu. Jeżeli wymagana byłaby jakakolwiek zmiana przed tym etapem, to bym ją wprowadził.

Wg. Agile / TDD to złe metodyki.
Ale oczywiście można uznać, że są dobre. :)Jakub Wojt edytował(a) ten post dnia 12.11.12 o godzinie 23:01

Temat: TDD, testowanie i inne takie

Jak na podstawie czterech zdań "zen" można stworzyć jakożkolwiek skuteczna metodę realizacji projektów (przy założeniu, że taka istnieje).

nie można ! :) co jest niejako oczywiste.

"Individuals and interactions over processes and tools"
Pewnie w nawiązaniu do tej zasady powstał Scurm i dobre praktyki ;)

Dla zrozumienia napiszę to samo o czym pisałem wcześniej (w poście który pociąłeś radośnie) - lecz uczynię to zgoła innymi słowami.
Otóż, onegdaj niektóre sposoby pracy - skąd inąd ignorujące całkowicie zdobycze inżynierii oprogramowania - były uznawane za amatorszczyznę i tak były traktowane. Obecnie, gdy gdzieś produkuje się soft systemem "na wariata" - to takie coś jest sprzedawana jako Agile. Inżynierowie oprogramowania mają w tym cyrku swój udział - zatem wnioskuję, że masa ludzi nie rozumie czym jest Agile.

To czym jest Agile, jeśli nie metodą "sprzedawania" softu produkowanego "na wariata" przez ludzi, którzy nie rozumieją, jak sam piszesz, "istoty agile" ?

Moja żonka (też informatyk) gdy przeczytała tę dyskusję stwierdziła: "I nad czym tu deliberować - przecież cały Agile sprowadza się do tego, by stosowaną metodykę dozbroić w cykliczne interakcje z klientem, a Wy piszecie i piszeeeecie... o czym tu pisać?"

Nie można sensownie interpretować tych czterech zdań (Agile manifesto). :)Jakub Wojt edytował(a) ten post dnia 12.11.12 o godzinie 22:08

Temat: TDD, testowanie i inne takie

Jakub Wojt:
W sumie nie widzę nic złego w pisaniu testu przed implementacją; ale jeśli później ktoś (entuzjasta TDD) albo coś (TDD) zaleca "przetestowanie nieistniejącej funkcjonaliści" albo uzasadnia kolejność implementacji "skupieniem się na wymaganiach podczas implementacji testów" to ciężko mi nie odnieść wrażenia, że mam kontakt z wariatem / oszustem / matołkiem.

TDD to technika, która może Ci pomóc albo nie i jeżeli, stosując ją, dostrzegasz zalety, to nie przerywasz tego (i przypuszczalnie polecasz dalej, skoro Tobie odpowiadają i przynoszą pozytywne rezultaty). Jeżeli natomiast Ci nie pomagają w niczym, to tego nie praktykujesz.
I, tak jak pisałem, jeżeli to programista/tester jest odpowiedzialny za stworzenie scenariuszy, to tak, ta technika pomaga skupić się na wymaganiach.

Czym innym jest pytanie:

Jak rozumiem, nie widzisz niczego absurdalnego w sytuacjach, w których jak określiłeś, "sprawdza się TDD"

Nie widzę nic absurdalnego, choć nie ukrywam, że dużo lepiej byłoby mieć gotowy projekt i zestawy testowe przed rozpoczęciem implementacji. Jednak nie żyjemy w idealnym świecie.

Z drugiej strony, kto komu broni uznania za normę przekroczenie terminów, kosztów albo faktu niedostarczenia aplikacji spełniającej wymagania ( agile -i tdd- nie specyfikuje metody definiowania wymagań, wiec ten problem chyba "ich" nie dotyczy).

A kto uznaje coś takiego za normę? Wszystkie techniki/metodyki/etc. (nawet te najbardziej absurdalne) powstają przede wszystkim dlatego, że zależy nam na tym, aby klient dostał wysokiej jakości produkt, w cenie i czasie, które go usatysfakcjonują.

Każdy robi tak, aby było jak najlepiej, a że niektórzy wolą pisać testy przed i wg nich przynosi to pozytywne efekty, to dlaczego by mieli robić inaczej?

Bo TDD opisuje taką sytuację. Programista piszący funkcjonalność przed testem nie skupia się dostatecznie na wymaganiach! :D

Nie, oczywiście, że się skupia, ale pisząc testy przed implementacją, może jeszcze przez chwilę spojrzeć na funkcjonalność oczami użytkownika i zastanowić się, jakie sytuacje musi przewidzieć. I tak, jak pisałem wcześniej, ten argument nie istnieje, gdy mamy gotowe scenariusze testowe.

Jeśli jego definicję dostarczył mi analityk - to interface jak najbardziej ujrzał światło dziennie.

Jak najbardziej.

Jeśli ja projektuję interface - "światło dzienne" go nie ujrzy go do momentu, w którym uznam, że może.

Czyli do tej pory może się zmieniać:)

Temat: TDD, testowanie i inne takie

Z drugiej strony, kto komu broni uznania za normę przekroczenie terminów, kosztów albo faktu niedostarczenia aplikacji spełniającej wymagania ( agile -i tdd- nie specyfikuje metody definiowania wymagań, wiec ten problem chyba "ich" nie dotyczy).

A kto uznaje coś takiego za normę?

Np Scurm (bo TDD ten temat pomija) i jego entuzjaści. Oczywiście nie są tego świadomi.
Żeby oszacować koszt i czas wykonania trzeba zrobić projekt aplikacji / systemu czyli dokładnie opisać co i jak trzeba zrobić. Tylko wiedząc co się robi można szacować koszt / czas.

Scrum zakłada, że precyzyjna wiedza o aplikacji będzie dostarczana stopniowo a to z kolei oznacza, że na początku projektu, czyli w fazie szacowania kosztów / czasu nie wiadomo dokładnie co trzeba zrobić. Jeśli się nie wie dokładnie co trzeba zrobić, to niestety prognozy czasu / kosztu też są "niedokładne". A jak są niedokładne to nie ma żadnych przesłanek żeby sądzić, że się ich dotrzyma.

Wszystkie techniki/metodyki/etc. (nawet te najbardziej absurdalne) powstają przede wszystkim dlatego, że zależy nam na tym, aby klient dostał wysokiej jakości produkt, w cenie i czasie, które go usatysfakcjonują.

Hitler też "chciał dobrze" ;)

Każdy robi tak, aby było jak najlepiej, a że niektórzy wolą pisać testy przed i wg nich przynosi to pozytywne efekty, to dlaczego by mieli robić inaczej?

Bo TDD opisuje taką sytuację. Programista piszący funkcjonalność przed testem nie skupia się dostatecznie na wymaganiach! :D

Nie, oczywiście, że się skupia, ale pisząc testy przed implementacją, może jeszcze przez chwilę spojrzeć na funkcjonalność oczami użytkownika

kurcze, za lista "zadań programisty" zaczyna się robić na prawdę długa.

Temat: TDD, testowanie i inne takie

Jakub Wojt:

A kto uznaje coś takiego za normę?

Np Scurm (bo TDD ten temat pomija) [...]

A skoro TDD nie porusza tej kwestii, a temat dotyczy testów, to ja proponuję zostawić wątki poboczne:)

Wszystkie techniki/metodyki/etc. (nawet te najbardziej absurdalne) powstają przede wszystkim dlatego, że zależy nam na tym, aby klient dostał wysokiej jakości produkt, w cenie i czasie, które go usatysfakcjonują.

Hitler też "chciał dobrze" ;)

I nie zawsze wychodzi tak, jak byśmy chcieli. I niestety nikt nie znalazł żadnego złotego środka na sukces, a na chęciach kończy się nie tylko tam, gdzie zwinnie się prowadzi projekty:)

Nie, oczywiście, że się skupia, ale pisząc testy przed implementacją, może jeszcze przez chwilę spojrzeć na funkcjonalność oczami użytkownika

kurcze, za lista "zadań programisty" zaczyna się robić na prawdę długa.

Moim zdaniem testując zawsze warto patrzyć na to, co testujemy jak użytkownik, a nie twórca. Dlatego lubię TDD, bo nie jestem jeszcze "obarczony" implementacją.

Temat: TDD, testowanie i inne takie

A kto uznaje coś takiego za normę?

Np Scurm (bo TDD ten temat pomija) [...]

A skoro TDD nie porusza tej kwestii, a temat dotyczy testów, to ja proponuję zostawić wątki poboczne:)

Ale porusza inne na tej samej zasadzie tzn. uznajmy brak "kompetencji" / "logicznego myślenia" za normę; wtedy wszystko będziemy robić "dobrze".

Wszystkie techniki/metodyki/etc. (nawet te najbardziej absurdalne) powstają przede wszystkim dlatego, że zależy nam na tym, aby klient dostał wysokiej jakości produkt, w cenie i czasie, które go usatysfakcjonują.

Hitler też "chciał dobrze" ;)

I nie zawsze wychodzi tak, jak byśmy chcieli.

"Wam" to chyba trochę częściej :)

I niestety nikt nie znalazł żadnego złotego środka na sukces,

Czy chcesz powiedzieć, że stosowanie jakiejś metodyki Agile nie gwarantuje niczego ? Jeśli tak - trzeba to powiedzieć ich entuzjastom: "to co robicie, zgodnie z metodyką, wcale nie musi przełożyć się na efekt. Taka metodyka.". :D

a na chęciach kończy się nie tylko tam, gdzie zwinnie się prowadzi projekty:)

A co trzeba zrobić, żeby nie kończyło się na "dobrych chęciach" ?
Stosować Scrumm, TDD ? Może po prostu nie wiesz co trzeba robić i dlatego piszesz, że "nie wiadomo". Na tym opiera się Agile; powstało ponieważ "nie można zrobić" pewnych rzeczy np. planu, projektu analizy etc .. i właśnie dlatego, te metodyki proponują "robienie na pałę", planu (bo jeśli projekt wypali, to plan się stworzył sam), projektu (bo to co powstanie będzie jakiś mieć) i analizy (bo przecież powstanie jakaś funkcjonalność).

Piękna metodyka realizacji projektów.

Nie, oczywiście, że się skupia, ale pisząc testy przed implementacją, może jeszcze przez chwilę spojrzeć na funkcjonalność oczami użytkownika

kurcze, za lista "zadań programisty" zaczyna się robić na prawdę długa.

Moim zdaniem testując zawsze warto patrzyć na to, co testujemy jak użytkownik

ale programista pewnie nigdy nie będzie użytkownikiem.
No ja wiem, w TDD to w niczym nie przeszkadza "wczuć się w rolę" ;DJakub Wojt edytował(a) ten post dnia 13.11.12 o godzinie 18:44

Temat: TDD, testowanie i inne takie

Jakub Wojt:
Ale porusza inne na tej samej zasadzie tzn. uznajmy brak "kompetencji" / "logicznego myślenia" za normę; wtedy wszystko będziemy robić "dobrze".

A w którym momencie uznaje brak "kompetencji" / "logicznego myślenia" za normę?
Jeszcze raz się zapytam - czy według Ciebie kolejność testowanie/implementowanie rzeczywiście świadczy o czymś takim?

I niestety nikt nie znalazł żadnego złotego środka na sukces,

Czy chcesz powiedzieć, że stosowanie jakiejś metodyki Agile nie gwarantuje niczego ?

Nie mam pojęcia skąd taki wniosek wysnułeś?

a na chęciach kończy się nie tylko tam, gdzie zwinnie się prowadzi projekty:)

A co trzeba zrobić, żeby nie kończyło się na "dobrych chęciach" ?

Używać technik, metodyk itp. dostosowanych do projektu, a nie 'tych ulubionych'. To zwiększa szanse powodzenia.

Moim zdaniem testując zawsze warto patrzyć na to, co testujemy jak użytkownik

ale programista pewnie nigdy nie będzie użytkownikiem.

Ale tester powinien traktować to, co testuje tak, jakby był użytkownikiem.

Temat: TDD, testowanie i inne takie

Witam wszystkich,

Calkiem przypadkiem natknalem sie na dyskusje tutaj prowadzona i po przeczytaniu niektorych postow jestem wrecz zatrwozony poziomem wiedzy na temat Agile'a/Scrum'a reprezentowanym przez wypowiadajace sie tutaj osoby, zwlaszcza te, ktore uwazaja sie za team liderow czy analitykow. Dlatego tez postanowilem zabrac glos i rzucic troche swiatla na pojecia, ktore wydaja sie byc dla niektorych czarna magia czy szamanizmem, a w grunice rzeczy sa banalnie proste, tylko zapewne nieumiejetnie zrozumiane.

Zacznijmy od tego skad w ogole czerpiecie informacje o Scrumie? Z wikipedii? Z ksiazki? Od kolegi? Byliscie na jakims szkoleniu ze Scruma? Pracowaliscie w Scumie jakis rozsadny okres czasu, powiedzmy, ze min. rok? Jesli tak, to w jakich rolach?

Nikt tutaj nie wydaje sie zdawac sobie sprawy po co tak naprawde Scrum jest wprowadzany i przez kogo. Otoz Scrum jest zwykle wprowadzany odgornie, przez management, bo to management musi widziec korzysci z jego wprowadzenia. A jakie to korzysci? Przede wszystkim TRANSPARENTNOSC! Inaczej przezroczystosc, widocznosc. Widocznosc czego? Postepu i problemow. Metodologia jest skonstruowana tak, zeby w kazdym momencie wiadomo bylo na czym sie stoi, a ewentualne przeszkody byly mozliwie najszybciej wykryte.

Polecam zapoznac sie np. z wykladem Kena Schwabera, zwanego jednym z "ojcow Scrum'a": http://www.youtube.com/watch?v=IyNPeTn8fpo
Zwlaszcza czesc od 13:34 do 15:06, gdzie mowi mniej wiecej o tym co napisalem powyzej.

Jezeli chodzi zas o TDD, to jego rozumienie jest zupelnie naturalne. Zanim chcesz cos napisac, musisz wiedziec jak to ma dzialac. Jezeli wiesz jak to dziala, to na zasadzie prostych przykladow z zadanym wejsciem, musisz wiedziec jakie jest oczekiwane wyjscie - i to jest juz test. Dlaczego wiec nie spisac najpierw tego testu, skoro jest juz on znany zanim rozpocznie sie implementacja? Takie podjescie wymusza bardzo dobra praktyke jaka jest programowanie przez prototypowanie, czy programowanie top-down, tylko z uzyciem interfejsow bez zadnej implementacji na poczatek.

Z TDD powiazane jest inne ciekawe, acz jeszcze mlode pojecie, executable specification, czyli tzw. wykonywalna specyfikacja. Widac, ze wiele jezykow dazy w tym celu - by stac sie rowniez meta-jezykami. W ten sposob, byc moze w niedalekiej przyszlosci, juz na etapie formulowania wymagan analitycy beda musieli programowac w meta-jezykach, co ma znacznie przyspieszyc przejscie od specyfikacji do implementacji. A w tym miejscu az prosi sie o uzycie TDD w postaci czegos w rodzaju "meta-testow akceptacyjnych". No ale to jeszcze poki co piesn przyszlosci.

To tyle ode mnie, bo nad kazdym z tematow mozna by sie duzo rozwodzic, a nie chce mi sie bawic w szkoleniowca, tylko wyeksponowac podstawowe bledy w pojmowaniu ideologii Scrum'a.

Temat: TDD, testowanie i inne takie

Maciej R.:
Calkiem przypadkiem natknalem sie na dyskusje tutaj prowadzona i po przeczytaniu niektorych postow jestem wrecz zatrwozony poziomem wiedzy na temat Agile'a/Scrum'a reprezentowanym przez wypowiadajace sie tutaj osoby, zwlaszcza te, ktore uwazaja sie za team liderow czy analitykow. Dlatego tez postanowilem zabrac glos i rzucic troche swiatla na pojecia, ktore wydaja sie byc dla niektorych czarna magia czy szamanizmem, a w grunice rzeczy sa banalnie proste, tylko zapewne nieumiejetnie zrozumiane.

Zacznijmy od tego skad w ogole czerpiecie informacje o Scrumie? Z wikipedii? Z ksiazki? Od kolegi? Byliscie na jakims szkoleniu ze Scruma? Pracowaliscie w Scumie jakis rozsadny okres czasu, powiedzmy, ze min. rok? Jesli tak, to w jakich rolach?

Kiedyś czytałem, że Scrum jest łatwy do zrozumienia, lecz trudny do zaimplementowania, lecz szczerze mówiąc ostatnio przestaje się z tym zgadzać.
Scrum jest pozornie prosty do zrozumienia. I właśnie to sprawia, że wiele osób, po przeczytaniu jednego artykułu w sieci, uważa się za ekspertów, a wszelkie późniejsze problemy z projektem zrzuca na karb tego frameworka.
Osobiście nie uważam się za żadnego specjalistę w tej dziedzinie, ale też temat nie dotyczy Scrum'a (niestety tak już nam jakoś ostatnio niefortunnie wychodzi, że kończy się na agile'u i wszystkim, co go dotyka:).

Co do doświadczenia w Scrumie, to ważniejsze od czasu spędzonego w nim, jest to, jak został on zaimplementowany. Jeżeli projekt i framework są dobrze dobrane, to z pewnością działa to na Twoją korzyść. Jeżeli jednak jesteś w projekcie, gdzie "wprowadzimy scruma, bo jest fajny, więc się na pewno u nas sprawdzi" (a tak jest niestety często), to masz duże szanse na nabycie złych przyzwyczajeń, a nie na dogłębne jego poznanie.

Z TDD powiazane jest inne ciekawe, acz jeszcze mlode pojecie, executable specification, czyli tzw. wykonywalna specyfikacja. Widac, ze wiele jezykow dazy w tym celu - by stac sie rowniez meta-jezykami. W ten sposob, byc moze w niedalekiej przyszlosci, juz na etapie formulowania wymagan analitycy beda musieli programowac w meta-jezykach, co ma znacznie przyspieszyc przejscie od specyfikacji do implementacji. A w tym miejscu az prosi sie o uzycie TDD w postaci czegos w rodzaju "meta-testow akceptacyjnych". No ale to jeszcze poki co piesn przyszlosci.

Czekam aż zobaczę coś takiego w akcji:)

Temat: TDD, testowanie i inne takie

Sebastian Malaca:

Widac, ze wiele jezykow dazy w tym celu - by stac sie rowniez meta-jezykami. W ten sposob, byc moze w niedalekiej przyszlosci, juz na etapie formulowania wymagan analitycy beda musieli programowac w meta-jezykach, co ma znacznie przyspieszyc przejscie od specyfikacji do implementacji. A w tym miejscu az prosi sie o uzycie TDD w postaci czegos w rodzaju "meta-testow akceptacyjnych". No ale to jeszcze poki co piesn przyszlosci.

Czekam aż zobaczę coś takiego w akcji:)

żaden problem, np. model dziedziny (klasy z operacjami) testuje się diagramami sekwencji, to działa, robię tak od dawna... oczywiście ma to sens dla nowo powstającego czegoś, test kompletnego scenariusza dla przypadku użycia na diagramie sekwencji to o niebo mniejsza pracochłonność niż napisanie tego kodu, testów TDD i puszczenie ich w ruch..

inny niż mój taki proces:
http://www.objectsbydesign.com/books/larman_process.html'Jarek Żeliński edytował(a) ten post dnia 16.11.12 o godzinie 11:27

Temat: TDD, testowanie i inne takie

Jarek Żeliński:

Sebastian Malaca:

Widac, ze wiele jezykow dazy w tym celu - by stac sie rowniez meta-jezykami. W ten sposob, byc moze w niedalekiej przyszlosci, juz na etapie formulowania wymagan analitycy beda musieli programowac w meta-jezykach, co ma znacznie przyspieszyc przejscie od specyfikacji do implementacji. A w tym miejscu az prosi sie o uzycie TDD w postaci czegos w rodzaju "meta-testow akceptacyjnych". No ale to jeszcze poki co piesn przyszlosci.

Czekam aż zobaczę coś takiego w akcji:)

żaden problem, np. model dziedziny (klasy z operacjami) testuje się diagramami sekwencji, to działa, robię tak od dawna... oczywiście ma to sens dla nowo powstającego czegoś, test kompletnego scenariusza dla przypadku użycia na diagramie sekwencji to o niebo mniejsza pracochłonność niż napisanie tego kodu, testów TDD i puszczenie ich w ruch..

inny niż mój taki proces:
http://www.objectsbydesign.com/books/larman_process.html'

Niestety, ale kompletnie nie zrozumiales o czym pisalem, a pisalem o automatycznym przejsciu ze specyfikacji do implementacji.

Piszesz, ze testujesz model diagramami sekwencji, ale jak? Na papierze? W jakiejs aplikacji? I co rozumiesz przez testowanie? Jak wprowadzasz dane testowe i jak weryfikujesz wyniki testow? Gdzie te testy sa skladowane? Jak raportowane sa wyniki tych testow? Ale najwazniejsze pytanie tutaj to: jak programisci moga uzyc tego co wyspecifkowales jako gotowego szablonu implementacji? Bo mam nadzieje, ze nie chodzi ci o przepisywanie wszystkiego z kartek...

To o czym piszesz, to zwykla specyfikacja za pomoca tekstu pisanego proza czy diagramow UML, stosowana od lat. Nic odkrywczego. Ja tutaj pisze o czyms zupelnie nowatorskim - pelen automatyzm: jesli specyfikacja jest programowalna, to testy akceptacyjne rowniez sa programowalne. Mozna wowczas napisac w pelni zautomatyzowany test akceptacyjny, ktory bedzie mozna uruchomic, zeby sprawdzic czy implementacja jest zgodna ze specyfikacja, a wyniki takiego testu automatycznie opublikowac w postaci raportu. Wszystko zgodnie z idea continuous integration.

A na koniec bardzo dobry przyklad tego, o czym pisalem wczesniej na temat wykonywalnej specyfikacji: http://geekswithblogs.net/JamesFleming/archive/2010/08...

Mam nadzieje, ze tym razem bedzie to poprawnie zrozumiane...

Temat: TDD, testowanie i inne takie

Maciej R.:
Niestety, ale kompletnie nie zrozumiales o czym pisalem, a pisalem o automatycznym przejsciu ze specyfikacji do implementacji.

realnie z uwagi na niealgorytmizowalny etap projektowania implementacji nadal utopia (modele generowane z automatu jak na razie są, na mój stan wiedzy, nadmiarowe i nieoptymalne,

Piszesz, ze testujesz model diagramami sekwencji, ale jak? Na papierze? W jakiejs aplikacji? I co rozumiesz przez testowanie?

przez testowanie rozumiem np. sprawdzenie, czy zaprojektowane klasy i ich operacje zrealizuja przypadek użycia.

Jak wprowadzasz dane testowe i jak weryfikujesz wyniki testow?

testowanie logiki systemu nie wymaga testu danych, pozostałe Twoje pytania to techniczna, mało istotna strona
[...] Wyrosłem już dawno z kartek

To o czym piszesz, to zwykla specyfikacja za pomoca tekstu pisanego proza czy diagramow UML, stosowana od lat. Nic odkrywczego.

być, może ale jak często spotykasz się z choćby z tym co opisałem powyżej a nie będącego "kartkami"? Bo ja ze słowami "diagramow UML, stosowana od lat" bym polemizował, zgodzę się z "znana od lat"...

Ja tutaj pisze o czyms zupelnie nowatorskim

chętnie zobaczę w realnym projekcie

A na koniec bardzo dobry przyklad tego, o czym pisalem wczesniej na temat wykonywalnej specyfikacji: http://geekswithblogs.net/JamesFleming/archive/2010/08...

jest także executive english i wiele innych ...

Mam nadzieje, ze tym razem bedzie to poprawnie zrozumiane...

jest zrozumiałe...

Temat: TDD, testowanie i inne takie

Jarku, czy Ty w ogóle jesteś w stanie zaakceptować sens stosowania testów automatycznych?

Temat: TDD, testowanie i inne takie

spotykam się często z tezą, że testy automatyczne są niemiarodajne.... to nie do mnie pytanie tylko do odpowiedzialnych za testy :), a każdym jeżeli pytanie dotyczy testów odbiorowych to ja nie dopuszczam, mają to zrobić użytkownicy na bazie specjalnie dobranych testowych procesów biznesowych.

po drugie pytanie: co na jakim etapie testujemy?
Na etapie analizy i projektu testujemy logikę i spójność projektu a nie dodawanie w polach faktury....

najprościej np. tak:
- mamy model CIM (omg.org/mda) - tu testujemy poprawność modelu procesów, wsad: dokumenty rzeczywiste, oczekiwane efekty: także te rzeczywiste
- mamy model PIM - tu testujemy logikę projektu jakość analizy i projektu obiektowego (zakładam, że od zera powstaje model dziedziny, nie zajmuje sie testowaniem bibliotek technicznych frameworka)
-

nie odpowiadam w projektach za jakość wytwarzanego kodu a za jakość odbieranego (dostarczonego) oprogramowania jako narzędzia pracy...

Temat: TDD, testowanie i inne takie

Jarek Żeliński:

Maciej R.:
Niestety, ale kompletnie nie zrozumiales o czym pisalem, a pisalem o automatycznym przejsciu ze specyfikacji do implementacji.

realnie z uwagi na niealgorytmizowalny etap projektowania implementacji nadal utopia (modele generowane z automatu jak na razie są, na mój stan wiedzy, nadmiarowe i nieoptymalne,

Ja bym tego utopia nie nazwal, bo obserwuje dazenia jezykow programowania w tym kierunku (meta-programowania, pisalem o tym w pierwszym poscie), ale masz prawo tego nie wiedziec, jesli nie interesujesz sie jezykami programowania.

Piszesz, ze testujesz model diagramami sekwencji, ale jak? Na papierze? W jakiejs aplikacji? I co rozumiesz przez testowanie?

przez testowanie rozumiem np. sprawdzenie, czy zaprojektowane klasy i ich operacje zrealizuja przypadek użycia.

Jak wprowadzasz dane testowe i jak weryfikujesz wyniki testow?

testowanie logiki systemu nie wymaga testu danych, pozostałe Twoje pytania to techniczna, mało istotna strona
[...] Wyrosłem już dawno z kartek

To ciekawe, bo najwyrazniej mamy odmienne rozumienie pojecia testowania. Co jest dowodem na powodzenie testu w takim podejsciu? Bo mam nadzieje, ze nie jakas subiektywna opinia w stylu "tak to powinno dzialac"...

To o czym piszesz, to zwykla specyfikacja za pomoca tekstu pisanego proza czy diagramow UML, stosowana od lat. Nic odkrywczego.

być, może ale jak często spotykasz się z choćby z tym co opisałem powyżej a nie będącego "kartkami"? Bo ja ze słowami "diagramow UML, stosowana od lat" bym polemizował, zgodzę się z "znana od lat"...

Spotykam sie z tym odkad pracuje, wiec pozwolisz, ze zostane przy swoim "stosowana od lat". Ponadto nie bierz pojecia "kartek" zbyt doslownie (mam nadzieje, ze cie nie ubodlo), bo elektroniczna wersje specyfikacji tez mozna wydrukowac, a przydatnosc jej jest taka sama jak tej papierowej. Chodzilo mi bardziej o jakosciowy kontrast: specyfikacja manualna/nieprogramowalna - specyfikacja automatyzowalna/programowalna.

Ja tutaj pisze o czyms zupelnie nowatorskim

Jarek Żeliński:
chętnie zobaczę w realnym projekcie

Sebastian Malaca:
Czekam aż zobaczę coś takiego w akcji:)

Jarek Żeliński:
żaden problem [...]

Ciesze sie, ze jednak podzielasz opinie kolegi Sebastiana i mam rozumiec, ze wycofujesz sie jednak ze slow "zaden problem"?

A na koniec bardzo dobry przyklad tego, o czym pisalem wczesniej na temat wykonywalnej specyfikacji: http://geekswithblogs.net/JamesFleming/archive/2010/08...

jest także executive english i wiele innych ...

Litosci... chyba nie chcesz mi powiedziec, ze nie rozrozniasz executive i executable? Zreszta nie bardzo rozumiem co ten komentarz mial oznaczac?Maciej R. edytował(a) ten post dnia 16.11.12 o godzinie 15:58

Temat: TDD, testowanie i inne takie

Jarek Żeliński:
spotykam się często z tezą, że testy automatyczne są niemiarodajne.... [...]

Gorszej glupoty dawno nie slyszalem... Wspolczuje z jakimi ludzmi musisz pracowac. No chyba, ze podzielasz to zdanie, wowczas dalsza dyskusja nie ma dla mnie sensu...

Temat: TDD, testowanie i inne takie

Sebastian Malaca:

Jakub Wojt:
Ale porusza inne na tej samej zasadzie tzn. uznajmy brak "kompetencji" / "logicznego myślenia" za normę; wtedy wszystko będziemy robić "dobrze".

A w którym momencie uznaje brak "kompetencji" / "logicznego myślenia" za normę?
Jeszcze raz się zapytam - czy według Ciebie kolejność testowanie/implementowanie rzeczywiście świadczy o czymś takim?

ustalanie kolejnosci na rzeczch w przypadku ktorych wazny jest jedynie fakt wykonania imho jest dowodem na niekompetencje.

taki wspolczesny szamanizm (propaganda,marketing). juz sensowniejsze wydaje mi sie bieganie przed implementacja bo "uwalnia endorfiny i dodaje wigoru, pozytywnie wplywa na sile ducha i motywacje".

no i powiedz, ze tak nie jest :)
i wyobaz sobie, szefa ktory w ramach swoich kompetencji w temacie it zaleca bieganie

I niestety nikt nie znalazł żadnego złotego środka na sukces,

Czy chcesz powiedzieć, że stosowanie jakiejś metodyki Agile nie gwarantuje niczego ?

Nie mam pojęcia skąd taki wniosek wysnułeś?

a co gwarantuje uzycie agile (oprocz, wedlug mnie, faila) ?

a na chęciach kończy się nie tylko tam, gdzie zwinnie się prowadzi projekty:)

A co trzeba zrobić, żeby nie kończyło się na "dobrych chęciach" ?

Używać technik, metodyk itp. dostosowanych do projektu, a nie 'tych ulubionych'. To zwiększa szanse powodzenia.

czy wiedza zmniejsza ryzyko porazki ?

Moim zdaniem testując zawsze warto patrzyć na to, co testujemy jak użytkownik

ale programista pewnie nigdy nie będzie użytkownikiem.

Ale tester powinien traktować to, co testuje tak, jakby był użytkownikiem.

a skad programista wie jak mysli / dziala uzytkownik ?Jakub Wojt edytował(a) ten post dnia 16.11.12 o godzinie 17:56

Temat: TDD, testowanie i inne takie

Maciej R.:

realnie z uwagi na niealgorytmizowalny etap projektowania implementacji nadal utopia (modele generowane z automatu jak na razie są, na mój stan wiedzy, nadmiarowe i nieoptymalne,

Ja bym tego utopia nie nazwal, bo obserwuje dazenia jezykow programowania w tym kierunku (meta-programowania, pisalem o tym w pierwszym poscie), ale masz prawo tego nie wiedziec, jesli nie interesujesz sie jezykami programowania.

obserwuje od lat prace nad sztuczną inteligencją, czekam...;)

To ciekawe, bo najwyrazniej mamy odmienne rozumienie pojecia testowania. Co jest dowodem na powodzenie testu w takim podejsciu? Bo mam nadzieje, ze nie jakas subiektywna opinia w stylu "tak to powinno dzialac"...

test to sprawdzenie zgodności testowanego czegoś z oczekiwanym wynikiem... jest procedura testowa, i wynik testu jest albo pozytywny albo negatywny, zapewniam, że nie jest to subiektywna opinia

Ponadto nie bierz pojecia "kartek" zbyt doslownie (mam nadzieje, ze cie nie ubodlo), bo elektroniczna wersje specyfikacji tez mozna wydrukowac, a przydatnosc jej jest taka sama jak tej papierowej. Chodzilo mi bardziej o jakosciowy kontrast: specyfikacja manualna/nieprogramowalna - specyfikacja automatyzowalna/programowalna.

nie obrażam się, skoro się tym od lat zajmujesz to zapewne wiesz, że jest istotna różnica pomiędzy schematem a modelem wiec zgadzam się, ze wydrukowany obrazek jest kartka ale wydrukowany model nie raz nie jest modelem...

Ciesze sie, ze jednak podzielasz opinie kolegi Sebastiana i mam rozumiec, ze wycofujesz sie jednak ze slow "zaden problem"?

nie, ale zapraszam na szkolenie i warsztaty...

A na koniec bardzo dobry przyklad tego, o czym pisalem wczesniej na temat wykonywalnej specyfikacji: http://geekswithblogs.net/JamesFleming/archive/2010/08...

jest także executive english i wiele innych ...

Litosci... chyba nie chcesz mi powiedziec, ze nie rozrozniasz executive i executable? Zreszta nie bardzo rozumiem co ten komentarz mial oznaczac?

literówka automatu od ortografii ;) ... przepraszam...

mam wrażenie, że to Ty bierzesz (tu moje) wątpliwości za atak na to co piszesz, nie, po prostu ja także nie zacząłem wczoraj z IT... najwyraźniej mamy różne doświadczenia i nie ma w tym nic złego... warto się nimi wymieniać, oczekujesz szanowania tego co piszesz o swojej pracy, szanuj inne doświadczeniaJarek Żeliński edytował(a) ten post dnia 16.11.12 o godzinie 19:49

Temat: TDD, testowanie i inne takie

Maciej R.:

Jarek Żeliński:
spotykam się często z tezą, że testy automatyczne są niemiarodajne.... [...]

Gorszej glupoty dawno nie slyszalem... Wspolczuje z jakimi ludzmi musisz pracowac. No chyba, ze podzielasz to zdanie, wowczas dalsza dyskusja nie ma dla mnie sensu...

nie mam kompetencji by to ocenić, jak z kimś pracuje w projekcie to tak długo jak w tym projekcie ten ktoś pracuje i pełni ustaloną role słucham go.

Może powiedz mi co nazywasz "testem automatycznym" bo być może mamy nieporozumienie...