Na YT opublikowano moją prezentację z zeszłorocznej konferencji JDD: https://www.youtube.com/watch?v=znRByMgnFSM
Czego możesz się z niej dowiedzieć:
- jeżeli testy używają Mocków "to wiedz, że coś się dzieje"
- jeżeli w typowym projekcie biznesowym dąży się do pokrycia 80% "to wiedz, że coś się dzieje"
- jeżeli testy akceptacyjne są napisane językiem kontrolek UI
"to wiedz, że coś się dzieje"
- jeżeli widzisz (anty) wzorzec Page Object
"to wiedz, że coś się dzieje"
a poza tym testy end-to-end powinny mieć warstwy - jak wszystko:)
...oraz jak działają automatyczne skrzynie biegów w super-samochodach.
Materiały: http://prezi.com/cxslyh5sqo_z/czego-mama-nigdy-nie-mowia-ci-na-temat-testowania-automatycznego/
5 komentarzy:
w okolicach 9:23 widać tylko jedną wersje kodu (dopiero dużo później jest faktycznie ta lepsza wersja). Dodatkowo zaciemniasz dodatkowym sprawdzeniem produktu ;), ale bardziej ciekawią mnie reakcję publiczności (np. kto używa mockito? Świetnieeee (a w oczach zawód;) ). Ponadto Pascala nie zna już prawie nikt, pokolenie dzisiejszych 21-letnich programistów to 1 na 100 mniej więcej.
Ogólnie prezentacja całkiem, całkiem.
Odnośnie kodu, to kwestia montażu, ale dodałem w poście linka do prezi - może pomóc gdyby ktoś chciał śledzić szczegóły.
Szkoda z tym Pascalem... ale zawsze można potraktować to jako smaczek dla zgredów:P A młodzi nie będą wiedzieć, że często w kodziku jest tak na prawdę Pascal ubrany w składnię Javy:P
A prezentacja... starałem się bardzo, a wyszło jak zwykle:P
Może zamiast Pascala lepiej porównać do ObjectiveC? Słabo go znam, ale z tego co się orientuję deklaracja klasy w ObjC składa się z sekcji deklaracji atrybutów (jak encja), interfejsu (jak interfejsy biznesowe) i z implementacji (jak klasa EJB). Z drugiej strony to trochę jak z tym programowaniem w strukturalnym C ale w paradygmacie obiektowym :)
Fajna prezentacja, po obejrzeniu pojawiły się w mojej głowie 2 pytania odnośnie BDD.
Widzę że masz poprawne spojrzenie na BDD. Poprawne tzn, nie pisz specyfikacji do UI/przycisków, ale pisz specyfikacje do reguł biznesowych. Sam musiałem wiele artykułów i konferencji przejrzeć by dojść do tego, bo w internecie dużo jest o BDD jako testowaniu UI. Czy masz podobne spostrzeżenia odnośnie tego ile jest złych przykładów jak stosować BDD?
Czy kiedykolwiek w większym projekcie zastosowałeś BDD z powodzeniem? Miałem okazje wprowadzić BDD gdy pisałem prace magisterską, to był mały projekcik 1 osobowy. Dla 1 osoby i małego projektu sprawdza się. Pytanie czy dla większych projektów z zespołem np. do 10 osób też się sprawdza? W Polsce słyszałem kilka opinii negatywnych o BDD że się nie sprawdza, że ciężko się utrzymuje itp. Jakie są twoje przemyślenia na ten temat?
W sumie to nie szukam jakoś specjalnie złych przykładów:)
Staram się wiedzę czerpać ze sprawdzonych źródeł.
Co do utrzymywania BDD to zależy właśnie od tego jak są napisane scenariusze akceptacyjne - jeżeli deklaratywnie i na odpowiednim poziomie abstrakcji, to będzie ok. Pytanie też z czym to porównywać, bo to, że coś kosztuje dużo pracy, to nie znaczy, że w innym podejściu kosztowałoby mniej...
Widziałem zastosowania BDD i Spec by Example w gigantycznych projektach i się sprawdzało.
Od razu chcę powiedzieć, że nie jestem jakimś "ewangelizatorem" BDD. Jest to jedna z metodyk, która ma swój obszar zastosowania w określonych klasach problemów - jak wszystko a poza tymi obszarami może być nawet szkodliwa - jak wszystko.
Szczególnie widać to w porównaniu do DDD: http://art-of-software.blogspot.com/2015/02/poaczenie-bdd-z-ddd.html
Prześlij komentarz