Temat: TDD, testowanie i inne takie

Jarek Żeliński:
po drugie w dobrym projekcie wymagania nie są przyjmowane od usera "na pałę" (Agile?) a "opracowywane" przez analityka ;)

No tak, to bardzo ważna rola w projekcie ;)

Temat: TDD, testowanie i inne takie

A dlaczego nie tak ?:
1. wymagania na interfejs (i na testy tego interfejsu)
2. implementacja testów / funkcjonalności w dowolnej kolejności
3. testy / akceptacja (lub jej brak) przekazanego kodu.
Kolejność test / implementacja nie ma znaczenia. Ważny jest fakt przeprowadzenia testów.
Zauważ Jarku, że Twój przykład zakłada pewną rzecz - stałość funkcjonalności i interfejsów. TDD powstało (jak każda metoda agile) w celu "radzenia sobie" z niestałością wymagań (ja to wolę nazywać "niekompetencją ludzi 'na przedzie' ").

Interfejs zawsze może się zmienić w trakcie refaktoryzacji...

co do kolejności trudno z tym polemizować, ale dodaj, że w trwającym cyklu życia produktu, powinien być (interfejs) kompatybilny wstecz i wiele Ci się wyjaśni...

można prosić o rozwinięcie myśli ?

po drugie w dobrym projekcie wymagania nie są przyjmowane od usera "na pałę" (Agile?) a "opracowywane" przez analityka ;)

Agile to takie ładne nazwanie podejścia "na pałę" ... :)
Agile to taka metodyka "dla ludzi" a nie dla "efektów", z resztą jaki normalny człowiek wysnułby jakiekolwiek praktyczne wnioski z tych czterech, (http://agilemanifesto.org/) śmierdzących zen i new age, zdań ?

Metodyka na podstawie czterech zdań ...
a może na podstawie jednego...albo braku jakiejkolwiek precyzyjnie przekazanej informacji.Jakub Wojt edytował(a) ten post dnia 07.11.12 o godzinie 19:42

Temat: TDD, testowanie i inne takie

co do kolejności trudno z tym polemizować, ale dodaj, że w trwającym cyklu życia produktu, powinien być (interfejs) kompatybilny wstecz i wiele Ci się wyjaśni...

można prosić o rozwinięcie myśli ?

to znaczy, że mimo rozwoju "myśli i systemu" warto by 'stare klasy" też miało z kim i jak pogadać....

Temat: TDD, testowanie i inne takie

Jakub Wojt:
Kolejność test / implementacja nie ma znaczenia. Ważny jest fakt przeprowadzenia testów.

Skoro kolejność nie ma znaczenia, to dlaczego tak bardzo przeszkadza Ci TDD? W końcu chodzi "jedynie" o kolejność:)

Zauważ Jarku, że Twój przykład zakłada pewną rzecz - stałość funkcjonalności i interfejsów. TDD powstało (jak każda metoda agile) w celu "radzenia sobie" z niestałością wymagań (ja to wolę nazywać "niekompetencją ludzi 'na przedzie' ").

Skoro kolejność nie ma znaczenia, to dlaczego osoby stosujące TDD nazywasz niekompetentnymi? I zaznaczam, że chodzi mi jedynie o TDD.

Interfejs zawsze może się zmienić w trakcie refaktoryzacji...

Której też nie uważasz za dobrą praktykę:)

Temat: TDD, testowanie i inne takie

Michał Wachowski:

...
Jeszcze nie miałem okazji pracować z porządnym agile.
W większości firm (z jakimi miałem styk), każdy jest rzucony samopas z ogólnymi wytycznymi (na ogół niewiele mówiącymi), a agile sprowadza się do tego, że klient jest dopytywany gdy trzeba :D

Ogólnie agile się chyba trochę pogubiło, albo pogubiło się raczej rozumienie Agile.
Obecnie dla wszystkich AGILE = WOLNOŚĆ OD WYMAGAŃ, KWITÓW, ITP....
a to nie tędy droga.

Reasumując - słowo "Agile" jest silnie nadużywane, i ochoczo przyklejane do wszystkiego, co charakteryzuje się brakiem jakiejkolwiek metodyki. Prawdą jest co napisał Michał - że
agile sprowadza się do tego, że klient jest dopytywany gdy trzeba :D by uciąć cięższą kwitologię na dopracowywaniu dupereli - jednak rynek rozszerzył zakres dopytywania, zlikwidował wszystko na czym można się oprzeć i tym oto sposobem (pseudo)agile sprowadza się do pytania klienta o wszystko w czasie ciągłym.... czyli praca bez metodyki, założeń, planu testów, czegokolwiek...

Temat: TDD, testowanie i inne takie

Jakub Wojt:

Agile to takie ładne nazwanie podejścia "na pałę" ... :)
Agile to taka metodyka "dla ludzi" a nie dla "efektów", z resztą jaki normalny człowiek wysnułby jakiekolwiek praktyczne wnioski z tych czterech, (http://agilemanifesto.org/) śmierdzących zen i new age, zdań ?

Metodyka na podstawie czterech zdań ...
a może na podstawie jednego...albo braku jakiejkolwiek precyzyjnie przekazanej informacji.

Hmm Agile to nie metodyka.
to dosyć dobrze opisuje czym jest agile http://agilescout.com/agile-is-not-a-methodology/

Temat: TDD, testowanie i inne takie

Jarek Żeliński:

co do kolejności trudno z tym polemizować, ale dodaj, że w trwającym cyklu życia produktu, powinien być (interfejs) kompatybilny wstecz i wiele Ci się wyjaśni...

można prosić o rozwinięcie myśli ?

to znaczy, że mimo rozwoju "myśli i systemu" warto by 'stare klasy" też miało z kim i jak pogadać....

co ma wspólnego "kompatybilność interfejsów" z "kolejnością pisania testów" ?

Temat: TDD, testowanie i inne takie

Jakub Wojt:

Jarek Żeliński:

co do kolejności trudno z tym polemizować, ale dodaj, że w trwającym cyklu życia produktu, powinien być (interfejs) kompatybilny wstecz i wiele Ci się wyjaśni...

można prosić o rozwinięcie myśli ?

to znaczy, że mimo rozwoju "myśli i systemu" warto by 'stare klasy" też miało z kim i jak pogadać....

co ma wspólnego "kompatybilność interfejsów" z "kolejnością pisania testów" ?

właśnie kolejność nie koniecznie, fakt ich istnienia tak...

Temat: TDD, testowanie i inne takie

Jakub Wojt:
Kolejność test / implementacja nie ma znaczenia. Ważny jest fakt przeprowadzenia testów.

Skoro kolejność nie ma znaczenia, to dlaczego tak bardzo przeszkadza Ci TDD? W końcu chodzi "jedynie" o kolejność:)

bo dla pewnych ludzi ta kolejność ma wielkie znaczenie :)

Zauważ Jarku, że Twój przykład zakłada pewną rzecz - stałość funkcjonalności i interfejsów. TDD powstało (jak każda metoda agile) w celu "radzenia sobie" z niestałością wymagań (ja to wolę nazywać "niekompetencją ludzi 'na przedzie' ").

Skoro kolejność nie ma znaczenia, to dlaczego osoby stosujące TDD nazywasz niekompetentnymi? I zaznaczam, że chodzi mi jedynie o TDD.

Ponieważ swoje "kompetencje" próbują oprzeć na rzeczach które nie mają znaczenia.

Interfejs zawsze może się zmienić w trakcie refaktoryzacji...

Której też nie uważasz za dobrą praktykę:)

Dokładnie. Zmiana interfejsów to takie gaszenie pożaru benzyną.
Interfejs oznacza "stałość". "Nie ważne, co się dzieje w 'bebechach', ważne, że interfejs pozostaje niezmienny".Jakub Wojt edytował(a) ten post dnia 09.11.12 o godzinie 20:44

Temat: TDD, testowanie i inne takie

Jeszcze nie miałem okazji pracować z porządnym agile.
W większości firm (z jakimi miałem styk), każdy jest rzucony samopas z ogólnymi wytycznymi (na ogół niewiele mówiącymi), a agile sprowadza się do tego, że klient jest dopytywany gdy trzeba :D

Ogólnie agile się chyba trochę pogubiło, albo pogubiło się raczej rozumienie Agile.

Ale kto się w tym (jakie rozumowanie o agile jest błędne?) rozumieniu "pogubił" i na jakiej podstawie można to stwierdzić (na jakiej podstawie ktoś rozumuje "poprawnie") ?

Temat: TDD, testowanie i inne takie

Rafał Korszuń:

Jakub Wojt:

Agile to takie ładne nazwanie podejścia "na pałę" ... :)
Agile to taka metodyka "dla ludzi" a nie dla "efektów", z resztą jaki normalny człowiek wysnułby jakiekolwiek praktyczne wnioski z tych czterech, (http://agilemanifesto.org/) śmierdzących zen i new age, zdań ?

Metodyka na podstawie czterech zdań ...
a może na podstawie jednego...albo braku jakiejkolwiek precyzyjnie przekazanej informacji.

Hmm Agile to nie metodyka.
to dosyć dobrze opisuje czym jest agile http://agilescout.com/agile-is-not-a-methodology/

meh ... http://www.jillesvangurp.com/2011/12/03/scrum-agile-ma...

Temat: TDD, testowanie i inne takie

co do kolejności trudno z tym polemizować, ale dodaj, że w trwającym cyklu życia produktu, powinien być (interfejs) kompatybilny wstecz i wiele Ci się wyjaśni...

można prosić o rozwinięcie myśli ?

to znaczy, że mimo rozwoju "myśli i systemu" warto by 'stare klasy" też miało z kim i jak pogadać....

co ma wspólnego "kompatybilność interfejsów" z "kolejnością pisania testów" ?

właśnie kolejność nie koniecznie, fakt ich istnienia tak...

czy ta znaczy "rzeczy należy testować" ?

Temat: TDD, testowanie i inne takie

Jakub Wojt:
czy ta znaczy "rzeczy należy testować" ?

wiesz, jak kupujesz samochód osobowy? Co sprawdzasz wiedząc, że składa się z kilkudziesięciu tysięcy elementów... a mimo to wlewasz standardowe paliwo, kupujesz standardowe koła i opony ....

Temat: TDD, testowanie i inne takie

Jakub Wojt:

Skoro kolejność nie ma znaczenia, to dlaczego tak bardzo przeszkadza Ci TDD? W końcu chodzi "jedynie" o kolejność:)

bo dla pewnych ludzi ta kolejność ma wielkie znaczenie :)

I co z tego? Ich sprawa. To jest tak, jak z IDE, jeden woli A, drugi B, ale czy to jakiś problem?

Skoro kolejność nie ma znaczenia, to dlaczego osoby stosujące TDD nazywasz niekompetentnymi? I zaznaczam, że chodzi mi jedynie o TDD.

Ponieważ swoje "kompetencje" próbują oprzeć na rzeczach które nie mają znaczenia.

Możesz rozwinąć myśl, bo nie za bardzo rozumiem?

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

Martin Fowler pisał kiedyś o interfejsach publicznych i opublikowanych.
Zgodzę się z Tobą, że interfejs powinien pozostać niezmienny, jeżeli jest już opublikowany. W innym wypadku, jeżeli istnieje potrzeba, to nie widzę powodu, dlaczego miałbym go nie zmieniać, jeżeli zaszłaby taka potrzeba.

Temat: TDD, testowanie i inne takie

Jakub Wojt:

Jeszcze nie miałem okazji pracować z porządnym agile.
W większości firm (z jakimi miałem styk), każdy jest rzucony samopas z ogólnymi wytycznymi (na ogół niewiele mówiącymi), a agile sprowadza się do tego, że klient jest dopytywany gdy trzeba :D

Ogólnie agile się chyba trochę pogubiło, albo pogubiło się raczej rozumienie Agile.

Ale kto się w tym (jakie rozumowanie o agile jest błędne?) rozumieniu "pogubił" i na jakiej podstawie można to stwierdzić (na jakiej podstawie ktoś rozumuje "poprawnie") ?

gdybyś zamiast wycinać całą resztę treści mojego postu - przeczytał ją, to byś sam sobie odpowiedział na swoje pytanie :)

Temat: TDD, testowanie i inne takie

Skoro kolejność nie ma znaczenia, to dlaczego osoby stosujące TDD nazywasz niekompetentnymi? I zaznaczam, że chodzi mi jedynie o TDD.

Ponieważ swoje "kompetencje" próbują oprzeć na rzeczach które nie mają znaczenia.

Możesz rozwinąć myśl, bo nie za bardzo rozumiem?

"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ć". Może TDD zakłada, że programista nie skupia się na "funkcjonalności" w momencie implementacji, albo że analityk zarabia na błaznowaniu ....

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

Martin Fowler

Czy zdajesz sobie sprawę z tego, że "MF" to jeden z liderów "refaktoringu" :D

"martinfowler.com/
Object-oriented programming expert and consultant, one of the leaders in refactoring,"

Jeśli o mnie chodzi, wystarczy jakaś dobra argumentacja. Powoływanie się na "ekspertów od refaktoringu" nie jest dobrym argumentem na cokolwiek.Jakub Wojt edytował(a) ten post dnia 11.11.12 o godzinie 20:05

Temat: TDD, testowanie i inne takie

Ale kto się w tym (jakie rozumowanie o agile jest błędne?) rozumieniu "pogubił" i na jakiej podstawie można to stwierdzić (na jakiej podstawie ktoś rozumuje "poprawnie") ?

gdybyś zamiast wycinać całą resztę treści mojego postu - przeczytał ją, to byś sam sobie odpowiedział na swoje pytanie :)

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

Temat: TDD, testowanie i inne takie

Jakub Wojt:
"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. 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.
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?

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.

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.

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?
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ł.

Temat: TDD, testowanie i inne takie

Jakub Wojt:

Ale kto się w tym (jakie rozumowanie o agile jest błędne?) rozumieniu "pogubił" i na jakiej podstawie można to stwierdzić (na jakiej podstawie ktoś rozumuje "poprawnie") ?

gdybyś zamiast wycinać całą resztę treści mojego postu - przeczytał ją, to byś sam sobie odpowiedział na swoje pytanie :)

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.

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.

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ć?"

Temat: TDD, testowanie i inne takie

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ą" :)