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 mnie2. Czym jest BDD?3. Założenia BDD4. Czym jest Gherkin?5. Korzyści stosowania BDD6. Czym jest historyjka?7. Historyjka - budowanie kroków8. Pisanie w Gherkinie9. 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 fundsGiven the account balance is $100And the card is validWhen the Account Holder requests $20Then the ATM should dispense $20And the account balance should be $80And the card should be returned

Pisanie w Gherkinie

Przykład 2

Feature: Refund item

Scenario: Jeff returns a microwaveGiven Jeff has bought a microwave for $100And he has a receiptWhen he returns the microwaveThen Jeff should be refunded $100

Jak NIE pisać w Gherkinie

Przykład

Feature: User actions

Scenario: Print ticketGiven the login page is displayedWhen I enter userNameAnd I enter the userPasswordAnd I click the ticket buttonAnd I click the enter buttonAnd I click the enter buttonThen 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???