Gherkin - jak zostać
“poetą” w IT
O mnie
● Tomasz Górski
● Pracuję na stanowisku testerskim, w firmie The Software House
● Doświadczenie w BDD:
Przez okres około sześciu miesięcy zajmowałem się pisaniem testów w
Gherkinie, na potrzeby klienta działającego w branży transportowej.
Obecnie zaczynam jako QAA.
Wstęp
1. O mnie
2. Czym jest BDD?
3. Założenia BDD
4. Czym jest Gherkin?
5. Korzyści stosowania BDD
6. Czym jest historyjka?
7. Historyjka - budowanie kroków
8. Pisanie w Gherkinie
9. Jak NIE pisać w Gherkinie
10. Podsumowanie
Wstęp - opis prezentacji
Celem prezentacji będzie pokazanie, jak poprawnie pisać testy w stylu BDD.
Pokażę jak konstruować zrozumiałe kroki, które będzie można wykorzystać
podczas dalszej pracy.
Poruszony temat zostanie rozwinięty przez Szymona, od strony technicznej.
BDD – Behaviour Driven Development
● proces wytwarzania oprogramowania, powstały na podstawie TDD
● opracowany przez: Dan North
BDD – Behaviour Driven Development
„Behaviour-driven Development polega na tworzeniu oprogramowania przez
opisywanie jego zachowania, z perspektywy jego udziałowców.”
Dan North
BDD – Behaviour Driven Development
Założenia:
● podstawą całego procesu jest utworzenie wymagań
● najważniejszą cechą systemu jest jego zachowanie
● chęć zrozumienie potrzeb klienta
● uzyskanie maksymalnego zrozumienia pomiędzy programistami,
analitykami oraz klientem
● automatyzacja
Czym jest Gherkin?
● nietechniczny język zrozumiały dla “biznesu”
● wykorzystywany przez Cucumber (narzędzie)
● służy do opisywania zachowania systemu za pomocą przypadków
testowych
Korzyści stosowania BDD
● zespół programistyczny jest na bieżąco informowany o poprawności kodu
● wspieranie aplikacji w środowisku produkcyjnym (automatyzacja)
● “pomost” pomiędzy biznesem i programistą (Gherkin)
Czym jest historyjka?
Czyli spisane wymaganie klienta.
Składa się z:
● tytułu (powinien być zrozumiały dla każdego)
● narracji
● kryteriów akceptacji
Narracja historyjki
Powinna zawierać:
● opis funkcjonalności (co ma robić)
● kto jest użytkownikiem
● korzyści jakie przynosi funkcjonalność
Kryteria akceptacji - czyli nasz scenariusz
Scenariusz ma nazwę oraz zazwyczaj składa się z:
● Given - określa warunki początkowe, przedstawia aktora
● When - opisuje akcje, występujące zdarzenie
● Then - informuje o oczekiwanych rezultatach
Historyjka - budowanie kroków
Ogólne założenia oraz cele:
● krok powinien być generyczny
● krok powinien być zrozumiały
● krok powinien zawierać informacje o tym co ma się wykonać
● krok powinien zostać napisany w poprawnej angielszczyźnie
● kroki powinny być ze sobą spójne (sposób budowania zdań)
Historyjka - budowanie kroków
Przykłady
● Given I am logged in as a "$user"
● When I click the "$elementName" element
● Then the "$elementName" element is visible
Historyjka - budowanie kroków
Przykład implementacji kroku
● When I click the "$elementName" element
Pisanie w Gherkinie
Przed rozpoczęciem:
● należy sprawdzić wymagania dla konkretnej funkcjonalności
● stworzyć plik .feature (nazwa powinna się pokrywać)
● dodać narrację dla historyjki
● dodać nazwę nowego scenariusza
Pisanie w Gherkinie
Przykładowe flow:
● sprawdzić istniejące kroki
● składnię nowego kroku najlepiej przygotować podczas pisania scenariusza
● dodać logikę dla nowych kroków
Pisanie w Gherkinie
Przykład 1
Feature: Account Holder withdraws cash
Scenario: Account has enough funds
Given the account balance is $100
And the card is valid
When the Account Holder requests $20
Then the ATM should dispense $20
And the account balance should be $80
And the card should be returned
Pisanie w Gherkinie
Przykład 2
Feature: Refund item
Scenario: Jeff returns a microwave
Given Jeff has bought a microwave for $100
And he has a receipt
When he returns the microwave
Then Jeff should be refunded $100
Jak NIE pisać w Gherkinie
Przykład
Feature: User actions
Scenario: Print ticket
Given the login page is displayed
When I enter userName
And I enter the userPassword
And I click the ticket button
And I click the enter button
And I click the enter button
Then the ticket should be printed
Podsumowanie
● oszczędność czasu
● aktualna i zrozumiała dokumentacja
● możliwość podpięcia pod Continuous Integration
● szybszy feedback od klienta
● wymuszenie lepszego kontaktu z klientem
Zagadka
BDD po niemiecku:
● verhaltensgetriebene Softwareentwicklung
PYTANIA???
Gherkin - jak zostać poetą w IT

Gherkin - jak zostać poetą w IT

  • 1.
    Gherkin - jakzostać “poetą” w IT
  • 2.
    O mnie ● TomaszGórski ● Pracuję na stanowisku testerskim, w firmie The Software House ● Doświadczenie w BDD: Przez okres około sześciu miesięcy zajmowałem się pisaniem testów w Gherkinie, na potrzeby klienta działającego w branży transportowej. Obecnie zaczynam jako QAA.
  • 3.
    Wstęp 1. O mnie 2.Czym jest BDD? 3. Założenia BDD 4. Czym jest Gherkin? 5. Korzyści stosowania BDD 6. Czym jest historyjka? 7. Historyjka - budowanie kroków 8. Pisanie w Gherkinie 9. Jak NIE pisać w Gherkinie 10. Podsumowanie
  • 4.
    Wstęp - opisprezentacji Celem prezentacji będzie pokazanie, jak poprawnie pisać testy w stylu BDD. Pokażę jak konstruować zrozumiałe kroki, które będzie można wykorzystać podczas dalszej pracy. Poruszony temat zostanie rozwinięty przez Szymona, od strony technicznej.
  • 5.
    BDD – BehaviourDriven Development ● proces wytwarzania oprogramowania, powstały na podstawie TDD ● opracowany przez: Dan North
  • 6.
    BDD – BehaviourDriven Development „Behaviour-driven Development polega na tworzeniu oprogramowania przez opisywanie jego zachowania, z perspektywy jego udziałowców.” Dan North
  • 7.
    BDD – BehaviourDriven Development Założenia: ● podstawą całego procesu jest utworzenie wymagań ● najważniejszą cechą systemu jest jego zachowanie ● chęć zrozumienie potrzeb klienta ● uzyskanie maksymalnego zrozumienia pomiędzy programistami, analitykami oraz klientem ● automatyzacja
  • 8.
    Czym jest Gherkin? ●nietechniczny język zrozumiały dla “biznesu” ● wykorzystywany przez Cucumber (narzędzie) ● służy do opisywania zachowania systemu za pomocą przypadków testowych
  • 9.
    Korzyści stosowania BDD ●zespół programistyczny jest na bieżąco informowany o poprawności kodu ● wspieranie aplikacji w środowisku produkcyjnym (automatyzacja) ● “pomost” pomiędzy biznesem i programistą (Gherkin)
  • 10.
    Czym jest historyjka? Czylispisane wymaganie klienta. Składa się z: ● tytułu (powinien być zrozumiały dla każdego) ● narracji ● kryteriów akceptacji
  • 11.
    Narracja historyjki Powinna zawierać: ●opis funkcjonalności (co ma robić) ● kto jest użytkownikiem ● korzyści jakie przynosi funkcjonalność
  • 12.
    Kryteria akceptacji -czyli nasz scenariusz Scenariusz ma nazwę oraz zazwyczaj składa się z: ● Given - określa warunki początkowe, przedstawia aktora ● When - opisuje akcje, występujące zdarzenie ● Then - informuje o oczekiwanych rezultatach
  • 13.
    Historyjka - budowaniekroków Ogólne założenia oraz cele: ● krok powinien być generyczny ● krok powinien być zrozumiały ● krok powinien zawierać informacje o tym co ma się wykonać ● krok powinien zostać napisany w poprawnej angielszczyźnie ● kroki powinny być ze sobą spójne (sposób budowania zdań)
  • 14.
    Historyjka - budowaniekroków Przykłady ● Given I am logged in as a "$user" ● When I click the "$elementName" element ● Then the "$elementName" element is visible
  • 15.
    Historyjka - budowaniekroków Przykład implementacji kroku ● When I click the "$elementName" element
  • 16.
    Pisanie w Gherkinie Przedrozpoczęciem: ● należy sprawdzić wymagania dla konkretnej funkcjonalności ● stworzyć plik .feature (nazwa powinna się pokrywać) ● dodać narrację dla historyjki ● dodać nazwę nowego scenariusza
  • 17.
    Pisanie w Gherkinie Przykładoweflow: ● sprawdzić istniejące kroki ● składnię nowego kroku najlepiej przygotować podczas pisania scenariusza ● dodać logikę dla nowych kroków
  • 18.
    Pisanie w Gherkinie Przykład1 Feature: Account Holder withdraws cash Scenario: Account has enough funds Given the account balance is $100 And the card is valid When the Account Holder requests $20 Then the ATM should dispense $20 And the account balance should be $80 And the card should be returned
  • 19.
    Pisanie w Gherkinie Przykład2 Feature: Refund item Scenario: Jeff returns a microwave Given Jeff has bought a microwave for $100 And he has a receipt When he returns the microwave Then Jeff should be refunded $100
  • 20.
    Jak NIE pisaćw Gherkinie Przykład Feature: User actions Scenario: Print ticket Given the login page is displayed When I enter userName And I enter the userPassword And I click the ticket button And I click the enter button And I click the enter button Then the ticket should be printed
  • 21.
    Podsumowanie ● oszczędność czasu ●aktualna i zrozumiała dokumentacja ● możliwość podpięcia pod Continuous Integration ● szybszy feedback od klienta ● wymuszenie lepszego kontaktu z klientem
  • 22.
    Zagadka BDD po niemiecku: ●verhaltensgetriebene Softwareentwicklung
  • 23.