Gherkin - jak zostać poetą w IT
-
Upload
the-software-house -
Category
Technology
-
view
174 -
download
4
Transcript of Gherkin - jak zostać poetą w IT
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???