Temat: TDD, testowanie i inne takie

Damian Sromek:
Z tego co można wywnioskować po wypowiedziach Jakuba to pracuję dla super klientów, z super analitykami, super projektantami, super programistami i wszystkim super, więc w takim środowisku rzeczywiście głupim byłoby wdrażanie nowych technik.
Nic tylko pozazdrościć.

myślę, że ironizowanie nie jest dobrym pomysłem, Jakub może operuje skrajnościami ale moim zdaniem takie dyskusje uczą pokory, i wymagają troszkę ambitniejszych odpowiedzi niż "bo tak"... nawet jeżeli gdzieś nie ma racji to warto postarać się o jakiś logiczny wywód zamiast "Agile/TDD jest dobre bo każdy tak mówi".

Mogę z doświadczenia powiedzieć, że relatywnie małe projekty Agile w znanym środowisku radzą sobie bardzo dobrze, zaczynają się schody gdy rośnie złożoność logiki biznesowej a metody sprint/scrum itp. sprowadzają się do odkrywania wymagań metodą szczura w labiryncie.

Często słyszę, że metody zwinne w 20% czasu dostarczają 80% funkcjonalności. Warto tu jednak dodać, że owe mityczne 80% funkcjonalności dostarczone w 20% czasu to najczęściej proste, z minimalną logiką, CRUD’y. Schody zaczynają się gdy trzeba zaimplementować skomplikowaną logikę. Nie jest problemem implementacja usługi wystawienie faktury, schody się zaczynają, gdy np. cennik produktów przestaje być zbiorem wartości wpisywanych „z palca” a zaczyna być pewną logiką promocji, kosztów, cen bazowych i limitów kupującego… wtedy zwinne metody najczęściej się kończą… trzeba tę logikę najpierw zrozumieć, potem opisać, opracować model (pomysł na) implementacji i na końcu dopiero implementować.

Nie raz mam możliwość widzieć ten sam projekt realizowany „dwiema metodami” (jestem często angażowany do projektów nieudanych by zacząć jeszcze raz to samo). Z moich obserwacji i wyliczeń wynika, że projekty „zwinne” zaczynają mieć kłopoty gdy wartość pracy przekracza 75/100 tys. zł. Drugi przypadek, to projekty, w których logika systemu nie była znana i zrozumiana w momencie rozpoczęcia i jej złożoność zaskoczyła wszystkich.

Sugeruje operować konkretnymi przykładami i zrezygnować z górnolotnych Agile/SCRUM/Sprint bo to tylko metody zarządzania projektem i nic ponad to...

Co do TDD rozumiem to i traktuje jako testowanie interfejsów czyli "projektowanie i testowanie" wymagań na interfejsy. Problem w tym, że najpierw trzeba je skądś brać (dostać) ... jak tak pomyśleć, to dobrze opracowane wymagania przekazywane developerowi to model dziedziny systemu i właśnie specyfikacje interfejsów (klas dziedzinowych), developer mając je napisze sobie testy i zacznie implementację...

Uwierzcie mi, że w projektach większych (umowne 75 tys. i więcej) gdy coś nie wychodzi, z reguły analityków angażuje się by posprzątali po Agile a nie odwrotnie...Jarek Żeliński edytował(a) ten post dnia 04.11.12 o godzinie 22:07

Temat: TDD, testowanie i inne takie

Jarek Żeliński:

Co do TDD rozumiem to i traktuje jako testowanie interfejsów czyli "projektowanie i testowanie" wymagań na interfejsy. Problem w tym, że najpierw trzeba je skądś brać (dostać) ... jak tak pomyśleć, to dobrze opracowane wymagania przekazywane developerowi to model dziedziny systemu i właśnie specyfikacje interfejsów (klas dziedzinowych), developer mając je napisze sobie testy i zacznie implementację...

Developer może dostać testy przygotowane przez lidera zespołu.
Przynajmniej staram się tak robić gdy mam ludzi pod sobą.

Temat: TDD, testowanie i inne takie

Michał Wachowski:

Jarek Żeliński:
Co do TDD rozumiem to i traktuje jako testowanie interfejsów czyli "projektowanie i testowanie" wymagań na interfejsy. Problem w tym, że najpierw trzeba je skądś brać (dostać) ... jak tak pomyśleć, to dobrze opracowane wymagania przekazywane developerowi to model dziedziny systemu i właśnie specyfikacje interfejsów (klas dziedzinowych), developer mając je napisze sobie testy i zacznie implementację...

Developer może dostać testy przygotowane przez lidera zespołu.
Przynajmniej staram się tak robić gdy mam ludzi pod sobą.

a skąd założenia (wymagania) do testów?

Temat: TDD, testowanie i inne takie

Jarek Żeliński:

Michał Wachowski:

Jarek Żeliński:
Co do TDD rozumiem to i traktuje jako testowanie interfejsów czyli "projektowanie i testowanie" wymagań na interfejsy. Problem w tym, że najpierw trzeba je skądś brać (dostać) ... jak tak pomyśleć, to dobrze opracowane wymagania przekazywane developerowi to model dziedziny systemu i właśnie specyfikacje interfejsów (klas dziedzinowych), developer mając je napisze sobie testy i zacznie implementację...

Developer może dostać testy przygotowane przez lidera zespołu.
Przynajmniej staram się tak robić gdy mam ludzi pod sobą.

a skąd założenia (wymagania) do testów?

Różnie, przez te kilka lat wypracowałem sobie sposób.
Mielę klienta, staram się z niego wyciągnąć jak najwięcej by zrozumieć specyfikę domeny, co dla klienta jest ważne i historyjki (że tak przetłumaczę sobie user stories).
Po każdej rozmowie, robię sobie na szybko projekt na kartce - wtedy wychodzą mi rzeczy o które muszę dopytać albo nie jestem pewien czy dobrze zrozumiałem (w końcu nie jestem ekspertem dziedziny :) )
Gdy wiem wszystko, przygotowuję finalny projekt, modele. (pytanie brzmi - czy dobrze robię?)

I na tej podstawie (czyli tak jak piszesz - model/modele dziedziny), na podstawie interfejsów z modeli powstają testy.

Nie siadam do kodowania, puki nie mam obrazu modelowanej rzeczywistości (czy też modelowanego fragmentu).
Przerabiałem _zręczne_ metodologie. Staram się od nich trzymać jak najdalej, wprowadzają tylko chaos i irytują. Muszę wiedzieć co ma być na końcu.

Wyjątkiem są sytuacje, gdy piszę komponenty, własne rozwiązania - wtedy mam w głowie ideę, efekt końcowy. Często też pomysł jak to rozwiązać. Jednakże w praktyce, pierwotny pomysł może się okazać błędny, niewygodny w użyciu.
Tak czy siak - na pewnym etapie, obraz całości jest na tyle klarowny, że można stworzyć interfejsy i opisać je testami.
A te są cholernie przydatne, gdy po jakimś czasie, komponent ma być wzbogacony o nową funkcjonalność i być zgodny z już wykorzystującymi go elementami.

Temat: TDD, testowanie i inne takie

Michał Wachowski:
Mielę klienta, staram się z niego wyciągnąć jak najwięcej by zrozumieć specyfikę domeny, co dla klienta jest ważne i historyjki (że tak przetłumaczę sobie user stories).
Po każdej rozmowie, robię sobie na szybko projekt na kartce - wtedy wychodzą mi rzeczy o które muszę dopytać albo nie jestem pewien czy dobrze zrozumiałem (w końcu nie jestem ekspertem dziedziny :) )
Gdy wiem wszystko, przygotowuję finalny projekt, modele. (pytanie brzmi - czy dobrze robię?)

:), jak pomagają to są dobre, pytanie czy ktoś poza Tobą je rozumie, jeśli nie, przydaje się 'stadanrd" ;)

I na tej podstawie (czyli tak jak piszesz - model/modele dziedziny), na podstawie interfejsów z modeli powstają testy.

Nie siadam do kodowania, puki nie mam obrazu modelowanej rzeczywistości (czy też modelowanego fragmentu).
Przerabiałem _zręczne_ metodologie. Staram się od nich trzymać jak najdalej, wprowadzają tylko chaos i irytują. Muszę wiedzieć co ma być na końcu.

tez do tego doszedłem :)

Wyjątkiem są sytuacje, gdy piszę komponenty, własne rozwiązania - wtedy mam w głowie ideę, efekt końcowy. Często też pomysł jak to rozwiązać. Jednakże w praktyce, pierwotny pomysł może się okazać błędny, niewygodny w użyciu.

ale (ja je tak traktuję) komponent to "osobny samodzielny projekt z kontraktem w postaci interfejsu"... czyż nie?

Tak czy siak - na pewnym etapie, obraz całości jest na tyle klarowny, że można stworzyć interfejsy i opisać je testami.
A te są cholernie przydatne, gdy po jakimś czasie, komponent ma być wzbogacony o nową funkcjonalność i być zgodny z już wykorzystującymi go elementami.

Staram się nie raz ustanowić coś w rodzaju "treści kontraktu" czyli co musi dostać developer by "to" wykonać, wychodzi mi, że listę usług systemu (przypadki użycia i ich scenariusze) oraz model dziedziny na poziomie interfejsów, specyfikacje obiektów z tożsamością (wzory dokumentów, klasy z atrybutami). Czy taki "kontrakt" byłby OK? Zakładam, że scenariusze przypadków użycia (nie zawsze wszystkie) zawierają testy odbiorcze (testy tych usług systemu).

Temat: TDD, testowanie i inne takie

Jakub Wojt:

Sebastian Malaca:
O refaktoryzacji... schodzimy na waterfall vs agile:)
O tdd i testowaniu... to samo:P
Może rzeczywiście to pora na osobny wątek? Tylko, że co z tego by wyszło? Lubię takie dyskusję, ale nie ukrywajmy - są czysto akademickie.

:D

Pisz za siebie; nie wiem jak w przypadku innych uczestników, ale _swoje_ wnioski wysnuwam na podstawie _swoich_ doświadczeń.

Nie neguje niczyich kompetencji. Chodziło mi raczej o to, że taka dyskusja jest czymś w stylu: lepsze OOP, czy programowanie strukturalne? A odpowiedź jest moim zdaniem taka sama - to zależy:) Mnóstwo argumentów za i przeciw, które bez przykładów, po prostu się równoważą.

Jeżeli jednak dorzucimy do tego granicę zaproponowaną przez @Jarka Żelińskiego (75 tys.), to myślę, że wtedy byłoby pomiędzy nami więcej rzeczy, przy których byśmy się zgodzili.
Opierając się na swoim doświadczeniu również mogę potwierdzić, że praca przy projektach ją przekraczających, które stosują Agile, to często więcej problemów niż korzyści. Niestety czasami nie jest mi dane decydować o wszystkim i muszę radzić sobie z tym, co jest, stopniowo udoskonalając cały proces (czyli w moim obecnym przypadku - powolna zmiana scruma na jakieś bardziej iteracyjne podejście).

[...] testowanie przydaje się, bo:

Pozwala zweryfikować, czy dana rzecz spełnia jakieś warunki.
Bardzo przydatne kiedy się coś projektuje i chce się mieć pewność, że wszystko zadziała "tak jak zaplanował".

Dokładnie:) Czyli mam funkcjonalność do zrealizowania, mam wszystko, czego potrzebuję (włącznie z projektem) do jej realizacji, piszę testy i implementuję:)
To u nas działa dokładnie w ten sposób.

Nieprzechodzący test daje informacje tylko taką, że "coś działa niezgodnie z założeniami".
Jakie konkretne wnioski można wysnuć na podstawie takiej informacji w kontekście "zmiany" i braku konkretnych założeń (planów / projektu) ?

Jeżeli Twoje "niezgodnie z założeniami" oznacza "niezgodnie z wymaganiami" (tak jest wg mnie), to daje mi wiedzę, że dodając coś nowego, rozwijając funkcjonalność, wprowadziłem jakiegoś buga (może to być nawet głupia literówka:)

TDD - daje poczucie bycia kompetentnym ludziom niekompetentnym przez co Ci ludzie pozostaną "na zawsze" niekompetentni.

??? Czy pisanie testów przed implementacją, to według Ciebie oznaka niekompetencji? Bo do tego przecież tak naprawdę sprowadza się cała idea TDD. O ile jestem w stanie zrozumieć, że ktoś woli najpierw pisać, a później implementować, to nazywanie niekompetencją robienia czegoś odwrotnego? "Odrobinę" krzywdzące stwierdzenie.

Temat: TDD, testowanie i inne takie

Michał Wachowski:

Jakub Wojt:
Testowania - pozwala zweryfikować fakt czy dana rzecz spełnia swoją rolę.
TDD - daje poczucie bycia kompetentnym ludziom niekompetentnym przez co Ci ludzie pozostaną "na zawsze" niekompetentni. To znaczy: ograniczenie konkurencji, możliwość windowania cen poważnym klientom. Chyba stanę się wielkim zwolennikiem ogólnie pojętych metod agile ;)

Zależy jak postrzegasz TDD - jeżeli uważasz, że dzięki testom twój kod będzie bezbłędny to trzymaj się jak najdalej od TDD.
Jakiekolwiek testy nie informują o tym, że kod nie zawiera błędów a jedynie to, że spełnia zadane w teście warunki.
Tyle i tylko tyle.

Ale ja właśnie o tym piszę. Testy też można źle zaplanować.
Z drugiej strony odnoszę wrażenie, nie wiem czy słuszne, że w TDD nie istnieje pojęcie "złych testów". To znaczy - jeśli jest test (i to - uwaga - przed implemetacją), to znaczy, że jest "dobrze".Jakub Wojt edytował(a) ten post dnia 05.11.12 o godzinie 19:42

Temat: TDD, testowanie i inne takie

Jakub Wojt:
Z drugiej strony odnoszę wrażenie, nie wiem czy słuszne, że w TDD nie istnieje pojęcie "złych testów". To znaczy - jeśli jest test (i to - uwaga - przed implemetacją), to znaczy, że jest "dobrze".

na mój rozum Jakub kolejnosc jest taka:
1. wymagania na interfejs
2. opracowanie testy tego interfejsu na bazie wymagania
3. odpalenie testy po wykonaniu implemmentacji

jeżeli test padnie to znaczy, że klasa nie spełnia wymagań...

Temat: TDD, testowanie i inne takie

Jarek Żeliński:

Damian Sromek:
Z tego co można wywnioskować po wypowiedziach Jakuba to pracuję dla super klientów, z super analitykami, super projektantami, super programistami i wszystkim super, więc w takim środowisku rzeczywiście głupim byłoby wdrażanie nowych technik.
Nic tylko pozazdrościć.

myślę, że ironizowanie nie jest dobrym pomysłem, Jakub może operuje skrajnościami ale moim zdaniem takie dyskusje uczą pokory, i wymagają troszkę ambitniejszych odpowiedzi niż "bo tak"... nawet jeżeli gdzieś nie ma racji to warto postarać się o jakiś logiczny wywód zamiast "Agile/TDD jest dobre bo każdy tak mówi".

Przepraszam, trochę się droczę z Wami ;)

Myślę, że ty i Jakub macie dużo racji.
Niestety przedstawiacie Agile w dużo bardziej negatywnym świetle niż ja widzę go na codzień.

Ja też nie wyobrażam sobie bardzo dużego/drogiego projektu bez sensownego planowania - "Co chcemy stworzyć? Po co? Jak?"
Co nie wyklucza Agile-owego podejścia w jego realizacji.

Temat: TDD, testowanie i inne takie

Jakub Wojt:

Zależy jak postrzegasz TDD - jeżeli uważasz, że dzięki testom twój kod będzie bezbłędny to trzymaj się jak najdalej od TDD.
Jakiekolwiek testy nie informują o tym, że kod nie zawiera błędów a jedynie to, że spełnia zadane w teście warunki.
Tyle i tylko tyle.

Ale ja właśnie o tym piszę. Testy też można źle zaplanować.
Z drugiej strony odnoszę wrażenie, nie wiem czy słuszne, że w TDD nie istnieje pojęcie "złych testów".

TDD nie mówi absolutnie nic o samych testach, a jedynie o kolejności w jakiej są pisane, tworzysz je przed kodem, a nie odwrotnie.
Zły test jest zły, niezależnie od tego, czy jest napisany przed, czy po implementacji.

jeśli jest test [...], to znaczy, że jest "dobrze".

Pewnie również zdajesz sobie sprawę, że jeżeli ktoś ma takie przeświadczenie, jest to jedynie iluzoryczne poczucie bezpieczeństwa:)

Jarek Żeliński:
na mój rozum Jakub kolejnosc jest taka:
1. wymagania na interfejs
2. opracowanie testy tego interfejsu na bazie wymagania
3. odpalenie testy po wykonaniu implemmentacji

I mamy definicję TDD :)

Temat: TDD, testowanie i inne takie

Damian Sromek:
Ja też nie wyobrażam sobie bardzo dużego/drogiego projektu bez sensownego planowania - "Co chcemy stworzyć? Po co? Jak?"
Co nie wyklucza Agile-owego podejścia w jego realizacji.

Zwinność zwinności nie równa :), tu także Agile:
http://www.agilemodeling.com/

Temat: TDD, testowanie i inne takie

Damian Sromek:

Jarek Żeliński:

Damian Sromek:
Z tego co można wywnioskować po wypowiedziach Jakuba to pracuję dla super klientów, z super analitykami, super projektantami, super programistami i wszystkim super, więc w takim środowisku rzeczywiście głupim byłoby wdrażanie nowych technik.
Nic tylko pozazdrościć.

myślę, że ironizowanie nie jest dobrym pomysłem, Jakub może operuje skrajnościami ale moim zdaniem takie dyskusje uczą pokory, i wymagają troszkę ambitniejszych odpowiedzi niż "bo tak"... nawet jeżeli gdzieś nie ma racji to warto postarać się o jakiś logiczny wywód zamiast "Agile/TDD jest dobre bo każdy tak mówi".

Przepraszam, trochę się droczę z Wami ;)

Myślę, że ty i Jakub macie dużo racji.
Niestety przedstawiacie Agile w dużo bardziej negatywnym świetle niż ja widzę go na codzień.

Ja też nie wyobrażam sobie bardzo dużego/drogiego projektu bez sensownego planowania - "Co chcemy stworzyć? Po co? Jak?"
Co nie wyklucza Agile-owego podejścia w jego realizacji.

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 :DMichał Wachowski edytował(a) ten post dnia 06.11.12 o godzinie 14:31

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

Mimo wszystko pozostaje pytanie, czy wynika to z:
a) braku wiedzy na temat agile'a osób, które chcą zwinnie prowadzić projekt
b) wybór agile choć totalnie nie pasuje do projektu
c) błędów agile'a
Z moich obserwacji wynika, że powody to najczęściej a) i b).
Wybór pada na agile, bo przecież jest "fresh and funky" i "czytałem kiedyś artykuł, że jest zajebisty, a wszystko inne to samo zło".

I nie chodzi mi tutaj wcale o obronę zwinność, a jedynie o to, że wiele projektów jest tak prowadzonych nie dlatego, że jest to odpowiednie rozwiązanie, a dlatego, że "łatwo i szybko" można je zrozumieć. I choć można, to czytałem kiedyś (nie wiem, czy przypadkiem nie w przewodniku scrum'a), że (poprawna) implementacja, to już dużo cięższe zadanie.

Temat: TDD, testowanie i inne takie

Ale z większością rzeczy tak jest.
Z agile, z MVC i z TDD, DI Container itd.
Jest w projekcie bo jest modne - a nie dlatego, że projekt tego potrzebuje.Michał Wachowski edytował(a) ten post dnia 06.11.12 o godzinie 14:58

Temat: TDD, testowanie i inne takie

Sebastian Malaca:
że wiele projektów jest tak prowadzonych nie dlatego, że jest to odpowiednie rozwiązanie, a dlatego, że "łatwo i szybko" można je zrozumieć.

bardziej dosadnie nazwał to kiedyś pewien PM w mojej obecności pytając: "Panowie, wy to znacie metody obiektowe, potraficie projektować, znacie UML, macie wymagania czy będzie to projekt zwinny?"

Temat: TDD, testowanie i inne takie

Michał Wachowski:
Ale z większością rzeczy tak jest.
Z agile, z MVC i z TDD, DI Container itd.
Jest w projekcie bo jest modne - a nie dlatego, że projekt tego potrzebuje.

pociesz się, z UML jest podobnie jest moda (SIWZ zawiera wiec ryzujemy), wtedy powstają obrazki z nie modele.... i słusznie lecą do kosza...Jarek Żeliński edytował(a) ten post dnia 06.11.12 o godzinie 15:06

Temat: TDD, testowanie i inne takie

Jarek Żeliński:

Michał Wachowski:
Ale z większością rzeczy tak jest.
Z agile, z MVC i z TDD, DI Container itd.
Jest w projekcie bo jest modne - a nie dlatego, że projekt tego potrzebuje.

pociesz się, z UML jest podobnie jest moda (SIWZ zawiera wiec ryzujemy), wtedy powstają obrazki z nie modele.... i słusznie lecą do kosza...

Niestety często lecą do kosza dużo później niż powinny...

Temat: TDD, testowanie i inne takie

Z drugiej strony odnoszę wrażenie, nie wiem czy słuszne, że w TDD nie istnieje pojęcie "złych testów". To znaczy - jeśli jest test (i to - uwaga - przed implemetacją), to znaczy, że jest "dobrze".

na mój rozum Jakub kolejnosc jest taka:
1. wymagania na interfejs
2. opracowanie testy tego interfejsu na bazie wymagania
3. odpalenie testy po wykonaniu implemmentacji

jeżeli test padnie to znaczy, że klasa nie spełnia wymagań...

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

Temat: TDD, testowanie i inne takie

Damian Sromek:
Z tego co można wywnioskować po wypowiedziach Jakuba to pracuję dla super klientów, z super analitykami, super projektantami, super programistami i wszystkim super, więc w takim środowisku rzeczywiście głupim byłoby wdrażanie nowych technik.
Nic tylko pozazdrościć.

myślę, że ironizowanie nie jest dobrym pomysłem, Jakub może operuje skrajnościami ale moim zdaniem takie dyskusje uczą pokory, i wymagają troszkę ambitniejszych odpowiedzi niż "bo tak"... nawet jeżeli gdzieś nie ma racji to warto postarać się o jakiś logiczny wywód zamiast "Agile/TDD jest dobre bo każdy tak mówi".

Przepraszam, trochę się droczę z Wami ;)

Ciekawe, kim będzie ten "trzeci" ... Damian jest drugi ...

Myślę, że ty i Jakub macie dużo racji.
Niestety przedstawiacie Agile w dużo bardziej negatywnym świetle niż ja widzę go na codzień.

Aha, mam dużo racji, ale "w negatywnym świetle" ? ;)
Ok, "Wy" z kolei macie mało racji ale w pozytywnym świetle :P

Ja też nie wyobrażam sobie bardzo dużego/drogiego projektu bez sensownego planowania - "Co chcemy stworzyć? Po co? Jak?"
Co nie wyklucza Agile-owego podejścia w jego realizacji.

Jeśli ma się plan to po co jest agile ?Jakub Wojt edytował(a) ten post dnia 06.11.12 o godzinie 20:06

Temat: TDD, testowanie i inne takie

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

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