wtorek, 25 marca 2014

Czego mama nigdy nie mówiła Ci na temat testowania automatycznego

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:

Piotr Błaszyński pisze...

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.

Sławek Sobótka pisze...

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

Anonimowy pisze...

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 :)

Jakub Ożga ( jakub.ozga@o2.pl ) pisze...

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?

Sławek Sobótka pisze...

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