🚀 go-pugleaf

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.

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. 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. 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. DSL  
używany w RSpec w tym wypadku wygląda tak:

Story: Krótki opis tego co będziemy sprawdzać
   As ...
   I want to ...
   So that ...

   Scenario: krótki opis pierwszego scenariusza
     Given ...
     When ...
     Then ...

   Scenario: tytuł drugiego scenariusza
     Given ...
     When ...
     Then ...

To, co wpiszemy jako tytuł historii i scenariusza jest zupełnie dowolne,  
byle było krótkie i opisowe.  Treść szablonu "As, I want to, So that" nie  
będzie przetwarzana, więc w zasadzie jest też dowolna.  To, co w tym  
najciekawsze i czego nie uświadczysz w TDD, to możliwość wielokrotnego  
wykorzystania tych samych części zdań.

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

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.

--
Jarosław Zabiełło
http://blog.zabiello.com