Temat: TDD, testowanie i inne takie

Mateusz Kurleto:
Bottom line - ja się zgadzam, że wiele niepożądanych dla użytkownika systemu reakcji systemu możemy obsłużyć tanio lub drogo - to nie ma jednak wpływu na zasadność testowania czy korzyści płynące z TDD.
Jeśli klient wymaga taniej obsługi - trzeba sprawdzać czy obsługujemy tanio - jeśli drogiej to sprawdzać czy drogo - ale sprawdzić trzeba.

ok, nie zmienia to faktu, że klient podejmuje decyzje a nie dostawca, rolą dostawcy/analityka jest przedstawić rzetelnie "sytuację"..

pytając o oprogramowanie można otrzymać np. oferty:
- 100 tys. zł, wiesza sie raz na tydzień
- 1 mln., nigdy sie nie wiesza

decyduje klient bo tylko on zna realia swojej pracy i nie musi się z tego nikomu spowiadać, ważne by decyzje podejmował świadomie.

ogólnie odnoszę wrażenie, że owo TDD (i nie tylko) to jedna strona medali, po drugiej jest "potrzebuję oprogramowanie wystarczająco dobre a nie najlepsze na świecie".... ważne by określić swojej wymagania

Temat: TDD, testowanie i inne takie

Jarek Żeliński:
ok, nie zmienia to faktu, że klient podejmuje decyzje a nie dostawca, rolą dostawcy/analityka jest przedstawić rzetelnie "sytuację"..

pytając o oprogramowanie można otrzymać np. oferty:
- 100 tys. zł, wiesza sie raz na tydzień
- 1 mln., nigdy sie nie wiesza

decyduje klient bo tylko on zna realia swojej pracy i nie musi się z tego nikomu spowiadać, ważne by decyzje podejmował świadomie.

ogólnie odnoszę wrażenie, że owo TDD (i nie tylko) to jedna strona medali,

Jasne, że to tylko jedna strona medalu, ale właśnie techniki tego typu pozwalają twórcom oprogramowania mieć jak największą pewność, że to, co robią spełni wymagania klienta.

po drugiej jest "potrzebuję oprogramowanie wystarczająco dobre a nie najlepsze na świecie".... ważne by określić swojej wymagania

A testy pomagają programiście sprawdzić, czy rzeczywiście jest to "oprogramowanie wystarczająco dobre":)Sebastian Malaca edytował(a) ten post dnia 24.10.12 o godzinie 09:56

Temat: TDD, testowanie i inne takie

Sebastian Malaca:

po drugiej jest "potrzebuję oprogramowanie wystarczająco dobre a nie najlepsze na świecie".... ważne by określić swojej wymagania

A testy pomagają programiście sprawdzić, czy rzeczywiście jest to "oprogramowanie wystarczająco dobre":)

czyli rozumiem, że testów jest niezbędne minimum, tylko tyle ile trzeba...;)

Temat: TDD, testowanie i inne takie

Jarek Żeliński:
czyli rozumiem, że testów jest niezbędne minimum, tylko tyle ile trzeba...;)

Nie lubię takich stwierdzeń, ponieważ nie są jednoznaczne, bo czym jest "niezbędne minimum"? Dla każdego jest to coś innego, ale jeżeli miałbym się odnieść do własnego doświadczenia, to bym odpowiedział, że tak.

W moim wypadku tym "niezbędnym minimum" jest pewność, że element testowany zachowuje się tak, jak powinien, w każdym przypadku, który został przewidziany. Z drugiej jednak strony, czasami tych przypadków jest tyle, że decydujemy się na najbardziej graniczne lub/i problematyczne, więc nawet owo "minimum" nie zawsze musi być osiągnięte:)

Temat: TDD, testowanie i inne takie

Sebastian Malaca:

Jarek Żeliński:
czyli rozumiem, że testów jest niezbędne minimum, tylko tyle ile trzeba...;)

Nie lubię takich stwierdzeń, ponieważ nie są jednoznaczne, bo czym jest "niezbędne minimum"? Dla każdego jest to coś innego, ale jeżeli miałbym się odnieść do własnego doświadczenia, to bym odpowiedział, że tak.

to pytanie było świadome, jeżeli w projekcie "Dla każdego jest to coś innego" to pierwszy sygnał że coś nie tak jest z wymaganiami, konkretnie z ich weryfikowalnością i mierzalnością, w konsekwencji wyceny będą miały ogromny rozrzut.

W moim wypadku tym "niezbędnym minimum" jest pewność, że element testowany zachowuje się tak, jak powinien, w każdym przypadku, który został przewidziany.

jeżeli "zgodnie z dobrymi regułami" każde wymagania funkcjonalne powinno mieć w parze także wymaganie jakościowe (poza-funkcjonalne) to mamy odpowiedź na pytanie czym jest "niezbędne minimum"...

Temat: TDD, testowanie i inne takie

zdaje sobie sprawę, ze balansuję na granicy off-top ale to celowe: "autorzy" każdego testowania, 'Wy programiści", powinni mieć świadomość, że testy czemuś służą i nie jest tym czymś "testowanie"...

i nie ukrywam, że owe kategorie (jednostkowe itp..) tez chyba nie są doprecyzowane??? nie łapię tych testów... :( Jarek Żeliński edytował(a) ten post dnia 24.10.12 o godzinie 17:28

Temat: TDD, testowanie i inne takie

Jarek Żeliński:
zdaje sobie sprawę, ze balansuję na granicy off-top ale to celowe: "autorzy" każdego testowania, 'Wy programiści", powinni mieć świadomość, że testy czemuś służą i nie jest tym czymś "testowanie"...

Oczywiście. Testy umożliwiają osiągnięcie pewnego celu, który powinien być jasny i zrozumiały (w ten sam sposób:) dla wszystkich. Jeżeli brakuje celu, to nie ma potrzeby korzystać ze środków, które służą jego osiągnięciu. Jeżeli cel jest rozmyty, to również może być to (zazwyczaj jest:) powodem wielu problemów, ponieważ jest szansa, że na koniec testów będzie za mało, będą złe etc. lub za dużo, będą nieopłacalne itp.

i nie ukrywam, że owe kategorie (jednostkowe itp..) tez chyba nie są doprecyzowane???

Są, tylko jak to zazwyczaj bywa z takimi (na pozór) prostymi rzeczami, wiele osób poznaje zajawki na dany temat i po kilku (o ile) dniach czytania na dany temat, uważa się za specjalistę w danej dziedzinie. Niestety przeczytanie definicji to nie wszystko.
Ja sam cały czas dokształcam się w tym temacie, ponieważ im więcej wiem, tym więcej rodzi się pytań.

A tak w skrócie:
- testy jednostkowe - testowanie elementów (metod, klas itp.). Czy zachowują się tak, jak chcemy we wszystkich przypadkach, które obsługujemy.
- testy akceptacyjne - mają na celu potwierdzenie, że oprogramowanie spełnia wymagania funkcjonalne i jakościowe
- testy integracyjne - testowanie integracji pomiędzy aplikacjami
i to z pewnością nie koniec:)

nie łapię tych testów... :(

Potrzeby ich stosowania, czy tego, jak to działa w praktyce?Sebastian Malaca edytował(a) ten post dnia 25.10.12 o godzinie 10:57

Temat: TDD, testowanie i inne takie

fajny cytat "dla mnie" :), to rozumiem:

Warto pisać aplikacje w taki sposób, żeby można było je w całości obsługiwać za pomocą testów jednostkowych. Jak należy to rozumieć? Budując aplikację w taki sposób, że cała jej funkcjonalność dostępna jest bez interfejsu użytkownika, możesz każdy jej aspekt opisać za pomocą testów jednostkowych. To pozwala na wstępne testowanie zgodności aplikacji z wymaganiami wstępne, bo cały czas należy pamiętać, że testy jednostkowe to narzędzie, wspierające programistów, a nie testerów i jako takie nie może zastąpić testów aplikacji. (Wykorzystanie TDD wraz ze wzorcem MVVM).
źr.:
http://msdn.microsoft.com/pl-pl/library/wykorzystanie-...

Temat: TDD, testowanie i inne takie

Jarek Żeliński:
fajny cytat "dla mnie" :), to rozumiem:

Warto pisać aplikacje w taki sposób, żeby można było je w całości obsługiwać za pomocą testów jednostkowych. Jak należy to rozumieć? Budując aplikację w taki sposób, że cała jej funkcjonalność dostępna jest bez interfejsu użytkownika, możesz każdy jej aspekt opisać za pomocą testów jednostkowych.

Powiedzmy, że interfejsy tworzy się właśnie ze względu na testy ...

To pozwala na wstępne testowanie zgodności aplikacji z wymaganiami wstępne, bo cały czas należy pamiętać, że testy jednostkowe to narzędzie, wspierające programistów, a nie testerów i jako takie nie może zastąpić testów aplikacji. (Wykorzystanie TDD wraz ze wzorcem MVVM).

Wymagania co do aplikacji nie zmieniają się ? ;)
"Nie wiemy, co robimy, ok, to przynajmniej napiszmy testy. To jest dobra metodyka realizacji zadań o których się nie ma pojęcia."

Współczesne IT to taki "dom wariatów" ...

TDD, MVVM i pewnie jeszcze Scrum w jedym projekcie... dżizas :)

Temat: TDD, testowanie i inne takie

Jakub, nie koniecznie. Wyobraź sobie, że docelowo ma powstać samochód, zaprojektowałeś (zleciłeś komuś) między innymi silnik, spokojnie możesz mieć wstępnie zaprojektowaną hamownię do testowania silnika (test jednostkowy), i nie ma znaczenia do jakiego docelowo nadwozia (View) zamontujesz ten silnik, masz możliwość sprawdzenia go, a parametry hamowni niejako wyznaczają wymagania na ten silnik.

Zwróć także uwagę, że wymagania na samochód mogą się zmieniać ale na prawdę mało, które przełoży się silnik.....

Akurat to "rozumiem" nawet na etapie analizy i projektowania i ma to sens, rozkręć swój komputer i zobacz jak jest skonstruowany ... każdy producent procesora, karty video czy kości pamięci jest w stanie testować swoje produkty i nie musi to być test kompletnego komputera....

OD dwóch dni grzebię w książkach i sieci, pomijają masę chłamu, TDD/MVVM ma głęboki sens...Jarek Żeliński edytował(a) ten post dnia 26.10.12 o godzinie 22:12

Temat: TDD, testowanie i inne takie

Jakub Wojt:

Jarek Żeliński:
fajny cytat "dla mnie" :), to rozumiem:

[i]Warto pisać aplikacje w taki sposób, żeby można było je w całości obsługiwać za pomocą testów jednostkowych. Jak należy to rozumieć? Budując aplikację w taki sposób, że cała jej funkcjonalność dostępna jest bez interfejsu użytkownika, możesz każdy jej aspekt opisać za pomocą testów jednostkowych.

Powiedzmy, że interfejsy tworzy się właśnie ze względu na testy ...

Skąd taki wniosek?

Wymagania co do aplikacji nie zmieniają się ? ;)
"Nie wiemy, co robimy, ok, to przynajmniej napiszmy testy. To jest dobra metodyka realizacji zadań o których się nie ma pojęcia."

Powiem Ci, że wykorzystuję TDD, refaktoryzuję kod, a projekt prowadzimy wg Scruma i wcale nie powiedziałbym, że nie wiem, co robię. Daleko mi również od stwierdzenia, że nie ma planów, ale nie o to chodzi w wątku.

Jeżeli uważasz, że TDD jest bezsensowne, to rzuć kilkoma argumentami, które albo można przeanalizować i przyznać Ci rację, albo spróbować je obalić, bo stwierdzenie

TDD, MVVM i pewnie jeszcze Scrum w jedym projekcie... dżizas :)

nie mówi absolutnie nic, poza Twoim podejściem do tych technik/metodyk. Jednak jakiś powód takiego, a nie innego podejścia być musi i może warto byłoby właśnie owe powody tutaj wypisać?

Mi osobiście TDD odpowiada i przyznaję się, że przekonywałem się do tego stopniowo i nie zawsze (szczególnie na początku) pisałem testy przed implementacją.
Jednak po pewnym czasie zacząłem dostrzegać rzeczywiste plusy. Pisanie tych testów przed, daje mi pewność, że wiem co robię. Jestem w stanie napisać test (co sprowadza się tak naprawdę do scenariusza użycia), czyli nawet bez kodu zdaję sobie sprawę, jak dana funkcjonalność ma działać.
Dodatkową zaletą jest to, że nie jestem jeszcze "skażony" implementacją, więc testując kod nie mam w głowie rozwiązania (a uwierz mi, że to wpływa na jakość testów).
Kolejnym argumentem "za" jest to, że po implementacji programista ma mniej motywacji do pisania tych testów, bo "przecież sam to napisałem, przewidziałem wszystkie możliwości, kod przejrzałem jeszcze kilka razy, to tak sobie klepnę ze dwa testy, żeby było, że przetestowane".

A co do samego pisania testów? Szczerze mówiąc nie wyobrażam sobie, żeby ich nie pisać. Nawet jeżeli masz gotowy projekt, przeanalizowane wymagania i wiesz na sto procent, że nic się nie zmieni, to ja wolałbym zainwestować tą odrobinę czasu, żeby napisać testy i wcześnie wyeliminować ewentualny błąd ludzki. Że można pisać tak, by nie było błędów? Pewnie da się, ale nie znam nikogo (i boję się, że nie poznam takiej osoby), kto by ich od czasu do czasu nie popełniał.Sebastian Malaca edytował(a) ten post dnia 27.10.12 o godzinie 00:18

Temat: TDD, testowanie i inne takie

Sebastian Malaca:
A co do samego pisania testów? Szczerze mówiąc nie wyobrażam sobie, żeby ich nie pisać. Nawet jeżeli masz gotowy projekt, przeanalizowane wymagania i wiesz na sto procent, że nic się nie zmieni, to ja wolałbym zainwestować tą odrobinę czasu, żeby napisać testy i wcześnie wyeliminować ewentualny błąd ludzki. Że można pisać tak, by nie było błędów? Pewnie da się, ale nie znam nikogo (i boję się, że nie poznam takiej osoby), kto by ich od czasu do czasu nie popełniał.

Ja wyobrażam sobie.
W sytuacjach gdy kod, klasa jest "ewolucyjny" i nie powstaje na podstawie żadnej dokumentacji a jedynie na podstawie idei, jako próba implementacji rozwiązania problemu.
W każdej innej sytuacji - warto robić test.

No i najważniejsze - test nie robi bezbłędnego kodu.
Sprawdza działanie w konkretnych przypadkach.
Zły test jest gorszy od braku testu, daje fałszywe poczucie "poprawnego działania".

function sum(a, b) {

return a*b;

}



sum(2,2) = 4 // ok

sum(1,1) = 1 // fail

:)

PS. Przykład Jarka z hamownią - idealny.

Temat: TDD, testowanie i inne takie

Jakub, nie koniecznie. Wyobraź sobie, że docelowo ma powstać samochód

Ale ja z tego doskonale zdaję sobie sprawę. Chodzi mi jedynie o to, że ktoś pisze "kod?" w "interfejsowej architekturze" w kontekście testów a nie zasad SOLID. Kod który jest pisany zgodnie z SOLID można łatwo testować, kod który piszę się dla testów (a nie SOLID) najprawdopodobniej będzie trudno testować.

Z resztą autor cytatu nawet nie zająkną się o interfejsach ("Warto pisać aplikacje w taki sposób, żeby można było je w całości obsługiwać za pomocą testów jednostkowych").

OD dwóch dni grzebię w książkach i sieci, pomijają masę chłamu, TDD/MVVM ma głęboki sens...

W inżynierii nie ma pojęcia "głęboki sens" ;)
Albo mamy coś co jest spójne z "naszą" wiedzą i ją powiększa, albo "to coś" jest "nieprzydatne".

Wiedza nie ma "sensu", tym bardziej "głębokiego".Jakub Wojt edytował(a) ten post dnia 27.10.12 o godzinie 20:51

Temat: TDD, testowanie i inne takie

Wymagania co do aplikacji nie zmieniają się ? ;)
"Nie wiemy, co robimy, ok, to przynajmniej napiszmy testy. To jest dobra metodyka realizacji zadań o których się nie ma pojęcia."

Powiem Ci, że wykorzystuję TDD, refaktoryzuję kod, a projekt prowadzimy wg Scruma i wcale nie powiedziałbym, że nie wiem, co robię.

Najprawdopodobniej nie wiesz. A jest tak, ponieważ _najprawdopodobniej_ nie wiesz, że nie wiesz.

W nawiązaniu do
http://en.wikipedia.org/wiki/Scrum_%28development%29

Daily Scrum
During the meeting, each team member answers three questions:[12]
- "What have you done since yesterday?"

Przerabiałem to, wiec mogę spokojnie skomentować - jeśli jakaś osoba pyta "co wczoraj zrobiłeś" to świadczy to jedynie o tym, że ta osoba nie wie "co wczoraj zrobiłeś". Dlaczego nie wie ? - ponieważ nie wydała konkretnych poleceń. Dlaczego ich nie wydała ? - ponieważ nie ma planu / harmonogramu i nie wie co robi.

Skoro "ona" nie wie co robi, na jakiej podstawie zakładasz, że Ty wiesz co robisz ?

- "What are you planning to do today?"
jw. "nie wydaję żadnych konkretnych poleceń, ale chcę, żeby ludzie pracowali". I ludzie pracują. Piszą klona "Entity Framework", "WPF", "wiedzą co robią" przez 3 lata po których mają jeden wielki b*rdel w kodzie (również w tym testującym) i zero pewności co odbioru aplikacji. A dead line (jedyna rzecz która została sensownie uzasadniona) jest "za niedługo". Z resztą data wykonania (w latach) i tak została wzięta z sufitu.

Może chodzi o to, żeby "moderator scruma" miał poczucie kontroli nad wytwarzaniem oprogramowania; nie wiem... :D

Albo robisz "scrum'a", albo wiesz co robisz ....

Jeżeli uważasz, że TDD jest bezsensowne, to rzuć kilkoma argumentami, które albo można przeanalizować i przyznać Ci rację, albo spróbować je obalić, bo stwierdzenie

TDD pomija kwestie związane z jakością analizy i projektu aplikacji.
Bez dobrej analizy i projektu nie ma czego testować... co nie znaczy, że nie można próbować.

TDD, MVVM i pewnie jeszcze Scrum w jedym projekcie... dżizas :)

nie mówi absolutnie nic, poza Twoim podejściem do tych technik/metodyk.

zgadza się.

Jednak jakiś powód takiego, a nie innego podejścia być musi i może warto byłoby właśnie owe powody tutaj wypisać?

TDD, Scrum, MVVM są głupie.
Analiza, projekt, harmonogram implementacji / testów są mądre. :D

Mi osobiście TDD odpowiada i przyznaję się, że przekonywałem się do tego stopniowo i nie zawsze (szczególnie na początku) pisałem testy przed implementacją.
Jednak po pewnym czasie zacząłem dostrzegać rzeczywiste plusy.
Pisanie tych testów przed, daje mi pewność, że wiem co robię.

Zapewniam, że nie ma to nic wspólnego z działającym softem.

Jestem w stanie napisać test (co sprowadza się tak naprawdę do scenariusza użycia), czyli nawet bez kodu zdaję sobie sprawę, jak dana funkcjonalność ma działać.
Dodatkową zaletą jest to, że nie jestem jeszcze "skażony" implementacją, więc testując kod nie mam w głowie rozwiązania (a uwierz mi, że to wpływa na jakość testów).
Kolejnym argumentem "za" jest to, że po implementacji programista ma mniej motywacji do pisania tych testów, bo "przecież sam to napisałem, przewidziałem wszystkie możliwości, kod przejrzałem jeszcze kilka razy, to tak sobie klepnę ze dwa testy, żeby było, że przetestowane".

A co do samego pisania testów? Szczerze mówiąc nie wyobrażam sobie, żeby ich nie pisać. Nawet jeżeli masz gotowy projekt, przeanalizowane wymagania i wiesz na sto procent, że nic się nie zmieni, to ja wolałbym zainwestować tą odrobinę czasu, żeby napisać testy i wcześnie wyeliminować ewentualny błąd ludzki. Że można pisać tak, by nie było błędów? Pewnie da się, ale nie znam nikogo (i boję się, że nie poznam takiej osoby), kto by ich od czasu do czasu nie popełniał.

można prosić o wersję w jednym / dwóch zdaniach ?Jakub Wojt edytował(a) ten post dnia 28.10.12 o godzinie 17:30

Temat: TDD, testowanie i inne takie

Jakub Wojt:
Kod który jest pisany zgodnie z SOLID można łatwo testować, kod który piszę się dla testów (a nie SOLID) najprawdopodobniej będzie trudno testować.

hm... jak to kiedyś słyszałem, nie ma znaczenia to czy ktoś jest uczciwy z natury czy dlatego, że ksiądz kazał, grunt że nie kradnie, Nie zmienia to faktu że uczciwego z natury nie trzeba pilnować... ale nauczyłem się, że należy to uszanować ;)

Z resztą autor cytatu nawet nie zająkną się o interfejsach

może uznał to za oczywiste.... sam się na tym łapię..

OD dwóch dni grzebię w książkach i sieci, pomijają masę chłamu, TDD/MVVM ma głęboki sens...

W inżynierii nie ma pojęcia "głęboki sens" ;)

w inżynierii wprost zapewne nie, ale w sztuce zapewne tak :), kiedyś broniliśmy tezy, że projektowanie t sztuka :)

Wiedza nie ma "sensu", tym bardziej "głębokiego".

ale ma sens posiadanie wiedzy ;)

Temat: TDD, testowanie i inne takie

Kod który jest pisany zgodnie z SOLID można łatwo testować, kod który piszę się dla testów (a nie SOLID) najprawdopodobniej będzie trudno testować.

hm... jak to kiedyś słyszałem, nie ma znaczenia to czy ktoś jest uczciwy z natury czy dlatego, że ksiądz kazał, grunt że nie kradnie, Nie zmienia to faktu że uczciwego z natury nie trzeba pilnować... ale nauczyłem się, że należy to uszanować ;)

Nie rozumiem analogii.

Z resztą autor cytatu nawet nie zająkną się o interfejsach

może uznał to za oczywiste.... sam się na tym łapię..

Może ta osoba nie powinna zajmować się "edukacją". Na dobrą sprawę - wszystko jest oczywiste, ale nie dla ludzi, którzy się uczą (czytają tutoriale).

OD dwóch dni grzebię w książkach i sieci, pomijają masę chłamu, TDD/MVVM ma głęboki sens...

W inżynierii nie ma pojęcia "głęboki sens" ;)

w inżynierii wprost zapewne nie, ale w sztuce zapewne tak :), kiedyś broniliśmy tezy, że projektowanie t sztuka :)

Z biegiem lat co raz częściej stwierdzam, że chodzi o "specjalistę" a nie o "artystę".
Na początku pewne rzeczy mogą wydawać się "magią", ale tak na prawdę wszystko jest kwestią wiedzy.

Wiedza nie ma "sensu", tym bardziej "głębokiego".

ale ma sens posiadanie wiedzy ;)

tautologia ! ;)

Temat: TDD, testowanie i inne takie

Jakub Wojt:

Wiedza nie ma "sensu", tym bardziej "głębokiego".

ale ma sens posiadanie wiedzy ;)

tautologia ! ;)

bez określenie o jaka wiedzę chodzi, nie :)

(nie, może nie mieć sensu dążenie do posiadania przeze mnie wiedzy o sposobie implementacji czegoś w jakimś egzotycznym języku)

Temat: TDD, testowanie i inne takie

Jakubie, po przeczytaniu Twoich wypowiedzi na temat TDD, Scrum, refaktoryzacji itd. aż mam ochotę zacząć programować w C# (czy czymkolwiek innym), żeby dostać się do firmy, w której pracujesz i popracować z Tobą przez kilka miesięcy.
Wygląda na to, że pracując w Waterfall-u (albo czymś bardzo podobnym) projekt(y?) odnosi sukces za sukcesem.

Nie zrozum mnie źle. Gratuluję sukcesów ale na prawdę ciężko jest mi sobie wyobrazić klienta a zwłaszcza wymagań, które pozwalają zakończyć cały projekt bez większych problemów.
No może jestem w stanie to sobie wyobrazić, kiedy klient dostarcza faktycznie wszystkich potrzebnych informacji bardzo dobrym analitykom, dzięki którym wymagania można idealnie przedstawić w specyfikacji itd.

Myślę, że Twoje podejście wynika z zupełnie innej sytuacji w projektach, w których pracowałeś i pracujesz.
Szczerze mówiąc trochę zazdroszczę, że możesz pracować w tak "przyjaznym" i spokojnym środowisku.

Pozdrawiam i życzę dalszych sukcesów zawodowych.

Temat: TDD, testowanie i inne takie

małe sprostowanie na temat wielkiego i strasznego potwora o nazwie Waterfall, którym straszy się dzieci na studiach informatycznych:

- w czasach analizy strukturalnej i takiegoż projektowania (lata 70/80'te) proces analizy i projektowania wymagał powstania kompletnego projektu całego, nawet wielkiego systemu

- określanie analizy i projektowania, poprzedzającego kodowanie, mianem Waterfall jest więc zwykłym nadużyciem i straszeniem ludzi sam nie wiem czym, to zupełnie nieuprawnione wywoływanie jakiegoś potwora z przed lat ...

- proces: analiza problemu, projekt rozwiązania, implementacja rozwiązanie to nie żaden mityczny Waterfall tylko zwykła, dobra i sprawdzona praktyka. Nikt rozsądny nie projektuje latami by potem latami kodować... projekty powinny być dobrze planowane i niekoniecznie na lata implementacji (od tego są programy czyli łańcuch projektów).

P.S.
Małe uzupełnienie: jedynym "waterfall'em" z jakim stale nadal się regularnie spotykam jest rozpoczynanie od projektu utworzenia bazy relacyjnej w 3. postaci normalnej pod cały system bo to własnie klasyczny waterfall... jaki powyżej opisałem (metody strukturalne)Jarek Żeliński edytował(a) ten post dnia 29.10.12 o godzinie 08:56

Temat: TDD, testowanie i inne takie

Jakub Wojt:
Najprawdopodobniej nie wiesz. A jest tak, ponieważ _najprawdopodobniej_ nie wiesz, że nie wiesz.

Po czym wnioskujesz? Po tym, że wykorzystuję techniki, które Tobie nie odpowiadają i ich nie stosujesz?

W nawiązaniu do
http://en.wikipedia.org/wiki/Scrum_%28development%29
[...]
Albo robisz "scrum'a", albo wiesz co robisz ....

To sobie podaruję, ponieważ nie jest na temat, a wydaję mi się, że główny wątek jest na tyle rozległy, że nie warto schodzić na tematy poboczne (bo zawsze można stworzyć w tym celu inny temat:).
Ja bym się pokusił jednak o delikatną parafrazę Twojego zdania:
Albo robisz Scrum'a i wiesz, co robisz, albo robisz "Scrum'a" i nie wiesz, co robisz.

TDD pomija kwestie związane z jakością analizy i projektu aplikacji.

To ja chyba coś przeoczyłem? W jaki sposób pomija?

TDD, Scrum, MVVM są głupie.
Analiza, projekt, harmonogram implementacji / testów są mądre.

No to mamy założenie, a dowód? Czy może jest to aksjomat?