2020-02-12, godz. 18:00
Często spotykam się ze stwierdzeniem, że wprowadzenie testów automatycznych kodu w projekcie nie jest łatwe. Zwykle nie ma na to czasu, klienci nie rozumieją dlaczego to ważne albo nie wszyscy w zespole są tak samo zaangażowani w testowanie. Brzmi znajomo? Pewnie wielokrotnie też słyszeliście, że nie ma sensu dążyć do 100% code coverage w testach. A czy przekonam Was, że tak naprawdę jest to dopiero początek drogi, którą trzeba przebyć, by móc cieszyć oko dobrze napisanymi testami i ze spokojem puścić deploy na produkcję w piątkowe popołudnie? Chciałbym opowiedzieć historię półtorarocznego projektu, w którym przeszliśmy drogę od totalnego braku testów, przez decyzję o ich wprowadzeniu i dotarciu do 100% code coverage, aż po problemy z zarządzaniem danymi i opisami testów. A to wszystko po to, by w końcu osiągnąć dojrzałe testy i przygotować plan dalszych działań, przy jednoczesnym rozwoju funkcjonalnym produktu.
Skrótowiec BDD (czyli Behavior Driven Development) prawie wszyscy znają, spora część wykorzystuje, a reszta głosi dobre słowo w community: że w komunikacji pomoże, że testy automatyczne usprawni, że pogodzi zwaśnione strony zespołu technicznego i biznesu.
Wszyscy mają, mam i ja! Aż wstyd nie mieć w projekcie testów zapisanych w formacie Given, When, Then. Przecież mówili, że BDD to lek na całe zło.
Tylko czy na pewno? Dla niektórych będzie kontrowersyjnie, ale zamierzam dość krytycznym okiem spojrzeć na BDD, które cieszy się dobrą opinią w community.
W trakcie prezentacji:
W prezentacji przedstawię użycie narzędzia "deptrac" w roli ochroniarza naszej architektury. Opowiem jak uchronić naszą starannie zaprojektowaną architekturę przed deadlinami, asapami, nieupilnowanymi stażystami czy pokusami szybkich fixów.
Przejdziemy przez:
