🚀 go-pugleaf

Jaroslaw Zabiello wrote:
> Dnia 11-08-2008 o 17:45:01 Seweryn Habdank-Wojewódzki 
> <habdank@gmail.com> napisał(a):
> 
>>> "Beyond Test Driven Development: Behaviour Driven Development
>>> "http://www.youtube.com/watch?v=oOFfHzrIDPk
>>
>> Super pogadanka. Dowiedziałem się, że prelegent napisał książkę o TDD.
>> Za chwilę dowiedziałem się, że TDD to "Bullshit", czyli jego książka
>> jako podzbiór TDD również.
> 
> Masz jakieś problemy z logiką. Książka może być przecież, dobrym, 
> kompetentnym opisem gównianej metodologii.
> 
>> bo zamiast koncentrować się na meritum sprawy, trzeba wiedzieć
>> że I.should.use.the.framework (framework_1).
> 
> Albo tego w ogóle nie przesłuchałeś tego tekstu, albo masz ciężki 
> problem z umiejętnością słuchania ze zrozumieniem, albo jesteś tak 
> uprzedzony, że nic ci nie pomoże.
> 
> Po pierwsze, składnia DSL'a używanego w BDD jest drugorzędna. BDD można 
> uprawiać nawet za pomocą klasycznych assertów (vide Shoulda). Więc się 
> nie błaźnij.

Błaźnisz to się ty, kolego inżynierze, nie znając historii.


> Po drugie, zasadnicza różnica między TDD a BDD dotyczy metodologii, 
> określenia tego co właściwie ma być testowane. No bo jak ktoś sam nie 
> wie, CO testuje, to nie świadczy o jego mądrości. Czym jest np. owa 
> "jednostka" w "testowaniu jednostkowym"? Kawałkiem klasy, funkcji, 
> skryptu? Wszystkim i niczym? TDD testuje jakieś fragmenty kodu.

Kolego, testy jednostkowe służą do testowania określonych przez projekt 
fragmentów kodu i weryfikacji podstawej zgodności z tymże projektem 
tychże właśnie fragmentów kodu (z tego projektu wynikających).

> BDD 
> proponuje natomiast aby testować to, czy aplikacja nasze względem niej 
> oczekiwania. Testera nie powinno obchodzić, czy dany algorytm działa tak 
> czy inaczej. Powinno go tylko obchodzić to, czy kod realizuje pokładane 
> w nim oczekiwania.

Testy funkcjonalne mają za zadanie weryfikować zgodność ze specyfikacją 
funkcjonalną.


> BDD nazywa specyfikacjami (specs). No dobrze. Ktoś 
> powie, że asserty to też takie same oczekiwania jak te should w RSpec 
> tylko, że wyrażone inną składnią. Otóż podobieństwo znika, gdy sięgnie 
> się po historie użytkownika, User Stories. Stały się one podstawą do 
> rozwiniętej części BDD jako Story Driven Development. W SDD definiuje 
> się listę oczekiwań wobec aplikacji. Oczekiwania są wyrażane w formie 
> scenariuszy  a scenariusze mogą być gromadzone razem w historie. Innymi 
> słowy, w SDD testuję to, czy aplikacja spełnia moję, określone 
> oczekiwania. Proste i logiczne. I także łatwe do wyjaśnienia dla osób 
> nietechnicznych.

Kolego inżynierze, przestań się błaźnić. Toż to jest znane od pół wieku. 
Oczywiscie bez bzdurnych nowych nazw BDD i SDD itd. Podzielone na 
scenariusze przypadki użycia (use cases) to typowy element specyfikacji 
funkcjonalnej. Wg nich wykonuje się testy systemu. Tylko to nie są żadne 
testy jednostkowe -- które Ty, kolego, jak i zarośnięty pan wodolej 
mylisz z testami funkcjonalnymi, integracyjnymi. itd.

Testy jednostkowe pisze programista, który zresztą, w wielu 
rzeczywistych projektach, ma obowiązek je wykonać przed oddaniem kodu do 
"wspólnego worka". Testy jednostkowe nie obejmują całości systemu, tylko 
właśnie zaprojektowane (i w ten sposób ściśle określone) elementy -- 
jednostki.


[...]
> Aby trochę otworzyć zasklepione umysły (u co niektórych), podam może 
> konkretny przykład jak wygląda kod takich testów w praktyce.

Wygląda kiepsko. Patrz niżej...


> Załóżmy, że 
> chcę sprawdzić czy działa mi formularz kontaktowy. Na początek stworzę 3 
> proste scenariusze.
> 
> Story: Contact via form
> 
>   As a potential customer
>   I want to send a message
>   So that I could know the message was delivered
> 
>   Scenario: Send required fields without email
>     Given 'name' field as 'Joe Doe'
>       And 'subject' field as 'Feedback'
>       And 'message' field as 'Hello!'
>     When I send the form
>     Then I should see 'thanx'
>       And fields should be saved in the database
> 
>   Scenario: Send required fields with invalid email
>     Given 'name' field as 'Joe Doe'
>       And 'subject' field as 'Feedback'
>       And 'message' field as 'Hello!'
>       And 'email' field as 'joe.doe@gmail'
>     When I send the form
>     Then I should see 'invalid email'
> 
>   Scenario: Send missing fields
>     Given missing 'name' field
>       Or missing 'subject' field
>       Or missing 'message' field
>     When I send the form
>       Then I should see 'missing name or subject or message'
> 
> Główny kod który przemieli te scenarusze (tu dla Rails) będzie wyglądał 
> mniej więcej tak:
> 
> steps_for(:contact) do
>   Given "'$what' field as '$value'" do |what, value|
>     @fields = {} unless @fields
>     @fields[what] = value
>   end
> 
>   Given "missing '$what' field" do |what|
>     @fields = {} unless @fields
>     @fields[what] = ""
>   end
> 
>   When "I send the form" do
>     post "/contact", :contact => @fields
>   end
> 
>   Then "I should see '$text'" do |text|
>     flash[:notice].should == text
>   end
> 
>   Then "fields should be saved in the database" do
>     Contact.create @fields
>   end
> end
>

Cóż...
1. A jak to stestuje przypadek gdy po najechaniu kursorka przeglądarka 
ma np. wyświetlić kalendarz (generowany JavaScriptem). Z punktu widzenia 
użytkownika toż to takie samo wymaganie jak napisanie "thanks".
2. Dla tej banalnej formy piszesz kawałek kodu parsującego testy, dla 
każdej bardziej skomplikowanej tego kodu musi być więcej. I jak tester 
zechce bardziej skomplikowane testy, których nie wymyślisz to musisz 
dopisywać kolejne -- znów słabo.
3. Tester który nie ma pojęcia o programowaniu i tak się ugotuje, bo 
nieprogramiści nie potrafią łatwo wbić się w ramy formalnego języka. 
Programiści tego nie rozumieją "no bo przecież to jest takie trywialne", 
ale to niezrozumienie nie zmienia rzeczywistości, w której pani Basia 
napisze:
Scenario: send required fields without email. When I send the form with 
  name as 'Joe Doe' and subject as 'Feedback' and email being 'Hello! 
Then I waht to see 'thanx' and then all must be saved in the db.
I oczywiście "zaatakowana" przez "wredny i złośliwy" komputer serią 
komunikatow o błędach absolutnie dla niej nie rozumiałych szurnie 
wszystko w cholerę.
4. Głupi bot sprzęgnięty z przeglądarką (są takie i za darmo) pozwoli 
pani Basi wklikać test, a programista będzie miał wolne, bo nie będzie 
musiał pisać RSpecowego kodu.


RSpec i podobne rzeczy nadaje się do testów jednostkowych i części 
testów integracyjnych (części, bo patrz punki 1 powyżej). Można nim 
wykonać też niektóre testy wydajnościowe i obciążenia.


> Oczywiście pomijam tu szczegóły dotyczące kodu szablonu HTML formularza 
> itp. bo nie chcę się bardziej rozpisywać. Dokładniejszy opis będzie 
> mojej książce.

No, to teraz jest wszystko jasne, skąd ta w telewizyjnym sztucznie 
luzackim stylu, reklama Rubiego na grupie o Pythonie :)

Jak nie wiadomo o co chodzi... :)

pzdr
-- 
"Never underestimate the power of human stupidity" -- L. Lang
-- 
http://www.tajga.org -- (some photos from my travels)