Quality Meetup

Oprogramowanie może być wytwarzane w oparciu o różne pomysły. Czasem napędzane jest przez powstającą dokumentację, czasem przez testy, a innym razem przez zachowanie samego systemu. Wśród software house’ów popularne stało się stosowanie BDD, ponieważ, przy budowaniu produktu, skupia się ono bardziej na potrzebach biznesowych niż na technicznych aspektach. Często stosowane jest także jako dodatkowa warstwa przy automatyzacji testów, gdyż wyniki ich wykonania są dzięki temu prezentowane w bardziej zrozumiały dla biznesu sposób.

W ciągu kilku lat pracy z BDD nastawienie Przemka do tego procesu ulegało zmianom — od początkowego zachwytu, poprzez zniechęcenie i podawanie w wątpliwość jego sensowności, aż do ponownego entuzjazmu. Przyczyną tego było wpadanie w kolejne pułapki i ślepe uliczki BDD, z których wiele wynikało z błędnego traktowania scenariuszy jako testów.
W czasie wykładu prelegent podzieli się ze słuchaczami swoimi przemyśleniami na temat Behavior-Driven Development. Wyjaśni także dlaczego, według niego, podczas pisania scenariuszy BDD, nie należy myśleć o ich implementacji w formie testów.