• Autor
• Blog
• Top 16
• Biblioteka
• Top YT
• Odnośniki

Szukaj:

• JavaScript
• Oprogramowanie
• Programowanie
• Testowanie

Spotkanie Koła Naukowego FullStack #4: Test Driven Development

Zasady tes­to­wa­nia opro­gra­mo­wa­nia zmie­nia­ły się na prze­strze­ni lat. Najpierw pro­gra­my by­ły te­sto­wa­ne głów­nie przez sa­mych twór­ców oraz użyt­kow­ni­ków koń­co­wych. Wraz z roz­wo­jem opro­gra­mo­wa­nia ko­mer­cyj­ne­go do pro­ce­su zo­sta­li włą­cze­ni pro­fe­sjo­nal­ni tes­te­rzy, któ­rych za­da­niem by­ło za­pew­nie­nie wy­so­kiej ja­koś­ci pro­gra­mów, choć­by by­ło to oku­pio­ne gnę­bie­niem pro­gra­mis­tów. W koń­cu, by zdjąć z tes­te­rów naj­bar­dziej mo­no­ton­ne za­da­nia i umoż­li­wić spraw­dza­nie w cią­gu pa­ru mi­nut, czy zna­ne wcześ­niej błę­dy nie po­wró­ci­ły wraz z no­wo wpro­wa­dzo­ny­mi zmia­na­mi, za­czę­to sto­so­wać te­sty auto­ma­tycz­ne.

Obecnie do te­stów auto­ma­tycz­nych za­li­cza­my jed­nost­ko­we, in­te­gra­cyj­ne, ca­ło­ścio­we (ang. end-to-end) oraz wie­le drob­niej­szych ka­te­gorii. Istnieje też wie­le me­to­do­lo­gii de­cy­du­ją­cych o tym, na ja­kim eta­pie roz­wo­ju wpro­wa­dzać te­sty auto­ma­tycz­ne i w ja­ki spo­sób je roz­wi­jać.

Jedną z cie­kaw­szych oraz mod­nych obec­nie tech­nik jest TDD, na­zy­wa­na też TFD. Zadania przed­sta­wie­nia jej szer­szej pub­licz­noś­ci pod­jął się Artur Dębski pod­czas czwar­te­go, ostat­nie­go w tym ro­ku spot­ka­nia Koła Naukowego Full­Stack, dzia­ła­ją­ce­go na Wydziale Auto­ma­ty­ki, Elektro­ni­ki i Informa­ty­ki Politech­ni­ki Śląskiej w Gli­wi­cach we współ­pra­cy z fir­mą Gorrion Software House. Jego pre­zen­tac­ja, za­ty­tu­ło­wa­na „Test Driven Develop­ment: jak te­sto­wać, że­by nie zwa­rio­wać (a przy­naj­mniej nie za bar­dzo)” mia­ła na ce­lu po­ka­za­nie za­let i wad tech­ni­ki oraz za­de­mon­stro­wa­nie jej uży­cia w prak­ty­ce.

Prelegent roz­po­czął od wy­jaś­nie­nia pod­staw tech­ni­ki. Cały pro­ces roz­wo­ju no­we­go ele­men­tu pro­gra­mu mu­si za­cząć się od za­pi­sa­nia te­stów do­ty­czą­cych pub­licz­ne­go API te­go mo­du­łu, za­nim jesz­cze po­wsta­nie choć je­den wiersz tek­stu źród­ło­we­go tes­to­wa­nej kla­sy lub me­to­dy. Bezpośred­nią ko­rzyś­cią z ta­kie­go po­dej­ścia jest obec­ność te­stów, któ­rych w przy­pad­ku wcześ­niej­sze­go im­ple­men­to­wa­nia funkcjo­nal­noś­ci nie chce się częs­to pi­sać. Chodzi jed­nak o du­żo wię­cej: za­pi­sa­nie te­stów, a więc ko­du wy­ko­rzy­stu­ją­ce­go no­wo two­rzo­ny mo­duł, przed im­ple­men­to­wa­niem API te­go mo­du­łu po­wo­du­je, że pro­gra­mis­ta jest zmu­szo­ny do prze­myś­le­nia, czy to API fak­tycz­nie speł­ni wy­ma­ga­nia użyt­kow­ni­ków. Jeżeli ko­rzy­sta­nie z mo­du­łu jest zbyt trud­ne, do­wie­my się o tym już pod­czas pi­sa­nia te­stów, a nie do­pie­ro przy pro­duk­cyj­nym wy­ko­rzys­ta­niu ko­du. Z te­go po­wo­du skrót „TDD” roz­wi­ja się cza­sem rów­nież ja­ko Test-Driven Design.

Ponadto, po­wsta­ją­ca im­ple­men­tac­ja bę­dzie od ra­zu na­pi­sa­na z myś­lą o moż­li­woś­ci sto­so­wa­nia te­stów auto­ma­tycz­nych. Dodawanie te­stów do ist­nie­ją­ce­go ko­du bar­dzo częs­to wią­że się z ko­niecz­noś­cią re­fak­to­ry­zo­wa­nia go i wy­ma­ga du­że­go (lub bar­dzo du­że­go) na­kła­du cza­su. Napisanie te­stów w pierw­szej ko­lej­noś­ci ozna­cza w ta­kim przy­pad­ku oszczęd­ność cza­su, gdyż two­rzo­na im­ple­men­tac­ja bę­dzie od ra­zu moż­li­wa do prze­te­sto­wa­nia.

Z obec­no­ści te­stów wy­ni­ka­ją oczy­wis­te ko­rzyś­ci. Najważniej­szą jest ochro­na przed re­gres­ją: je­że­li co­kol­wiek zmie­ni istot­ne z punk­tu wi­dze­nia pro­gra­mu za­cho­wa­nie te­sto­wa­ne­go ele­men­tu, mo­że­my wy­kryć i usu­nąć uster­kę za­nim tra­fi ona do klien­tów. W efek­cie wzras­ta po­ziom za­ufa­nia do ko­du, a pro­gra­miś­ci nie bo­ją się wpro­wa­dzać da­le­ko idą­cych zmian w im­ple­men­tac­ji. Testy sta­no­wią też naj­lep­szą moż­li­wą do­ku­men­tac­ję da­ne­go mo­du­łu funkcjo­nal­ne­go, gdyż sta­no­wią za­pis kon­trak­tów wej­ścio­wych i wyj­ścio­wych po­szcze­gól­nych pod­pro­gra­mów. Ostatecz­nie na­le­ży je za­tem uznać za ele­ment da­ją­cy zysk od­kła­da­ją­cy się w cza­sie: choć na po­cząt­ku bę­dzie­my uwa­żać, że pi­sa­nie te­stów zmniej­sza na­szą pro­duk­tyw­ność i wy­dłu­ża czas od po­mys­łu do pro­duk­tu, na eta­pie utrzy­ma­nia i re­fak­to­ry­za­cji ko­du spo­wo­du­ją one spo­rą oszczęd­ność cza­su, ner­wów, a być mo­że rów­nież pie­nię­dzy.

Testy auto­ma­tycz­ne po­win­ny być szyb­kie, aby pro­gra­mis­tów nie kor­ci­ło ich po­mi­ja­nie. Najwolniej­sze frag­men­ty ko­du, nie­istot­ne przy te­sto­wa­niu da­ne­go mo­du­łu funkcjo­nal­ne­go, po­win­ny być za­stę­po­wa­ne imi­tac­ja­mi (ang. mocks) tak, aby ope­rac­je trwa­ją­ce set­ki lub ty­sią­ce mili­se­kund rea­li­zo­wać w cią­gu po­je­dyn­czych mik­ro­se­kund. Stosując imi­ta­cje trze­ba jed­nak sta­le zwra­cać uwa­gę, by nie za­cząć te­sto­wać tych imi­ta­cji za­miast pro­duk­cyj­ne­go ko­du pro­gra­mu.

Podczas pi­sa­nia te­stów na­le­ży sku­pić się nie na im­ple­men­tac­ji, lecz na za­cho­wa­niu tes­to­wa­nych klas i pod­pro­gra­mów. Prelegent zde­cy­do­wa­nie sprze­ci­wił się wpro­wa­dza­niu do te­stów za­ło­żeń co do sta­nu obiek­tów, a tak­że od­ra­dził te­sto­wa­nie pry­wat­nych me­tod klas.

Poszczegól­ne te­sty po­win­ny skła­dać się z trzech częś­ci, wspól­nie reali­zu­ją­cych za­sa­dę „trzech A” (uważ­ni Czytelnicy mo­gą za­uwa­żyć po­do­bień­stwo te­go po­dzia­łu do given-when-then sto­so­wa­ne­go w tech­ni­ce BDD i opi­sa­ne­go w re­lac­ji z ze­szło­rocz­nej kon­fe­ren­cji SpreadIT):

• Arrange – przy­go­to­wu­je śro­do­wis­ko po­trzeb­ne do zrea­li­zo­wa­nia te­stu,
• Act – uru­cha­mia dzia­ła­nie pod­le­ga­ją­ce te­sto­wa­niu,
• Assert – okre­śla i we­ry­fi­ku­je za­ło­że­nia co do ak­cep­tac­ji wy­ni­ku te­stu.

Ponadto, wszyst­kie te­sty po­win­ny speł­niać za­ło­że­nia F.I.R.S.T., opi­sa­ne przez Rober­ta Martina w książ­ce „Clean code”:

• Fast – mu­szą być prze­bie­gać szyb­ko, szcze­gól­nie w śro­do­wis­ku TDD, w któ­rym bę­dą uru­cha­mia­ne set­ki lub ty­sią­ce ra­zy w trak­cie im­ple­men­to­wa­nia funkcjo­nal­noś­ci,
• Independent – nie mo­gą mieć trwa­łych skut­ków ubocz­nych, śro­do­wis­ko te­sto­we po­win­no być przed każ­dym tes­tem przy­wra­ca­ne do iden­tycz­ne­go sta­nu, a ko­lej­ność reali­zac­ji po­szcze­gól­nych te­stów nie mo­że mieć żad­ne­go zna­cze­nia,
• Repeatable – nie mo­gą być za­leż­ne od wa­run­ków zew­nętrz­nych, a ich wie­lo­krot­ne uru­cha­mia­nie bez zmia­ny te­sto­wa­ne­go ko­du mu­si zaw­sze da­wać ten sam wy­nik,
• Self-Validating – mu­szą bez in­ter­wen­cji użyt­kow­ni­ka da­wać jed­no­znacz­ny, zero-je­dyn­ko­wy wy­nik: al­bo test prze­biegł po­praw­nie, al­bo jed­no z za­ło­żeń nie zo­sta­ło speł­nio­ne,
• Timely – mu­szą być na­pi­sa­ne za­nim po­wsta­nie im­ple­men­tac­ja, aby unik­nąć im­ple­men­tac­ji nie zorien­to­wa­nej na te­sty oraz te­stów zorien­to­wa­nych na kon­kret­ną im­ple­men­tac­ję.

Jako źród­ło wie­dzy teo­re­tycz­nej i prak­tycz­nej pre­le­gent wy­mie­nił dwie książ­ki:

• Kent Beck: „Test-driven de­ve­lop­ment by exam­ple”,
• Steve Freeman, Nat Pryce: „Growing Object-Oriented Software, Guided by Tests”.

Druga część spot­ka­nia po­świę­co­na by­ła prak­tycz­nej pre­zen­tac­ji za­sto­so­wa­nia TDD. Prelegent po­sta­wił so­bie za za­da­nie za­pi­sa­nie w ję­zy­ku Java­Script me­to­dy greet() speł­nia­ją­cej wy­ma­ga­nia Greeting Kata. Kolejne, co­raz bar­dziej ab­strak­cyj­ne wy­ma­ga­nia opi­sa­ne w do­ku­men­cie pro­wa­dzi­ły do po­wsta­wa­nia ko­lej­nych te­stów, a bez­po­śred­nio po nich — do wpro­wa­dza­nia re­fak­to­ry­za­cji i roz­sze­rzeń ko­du. W pa­ru przy­pad­kach zmia­ny fak­tycz­nie psu­ły wcześ­niej dzia­ła­ją­cą funkcjo­nal­ność, jed­nak obec­ność te­stów po­zwa­la­ła szyb­ko to wy­kryć i wpro­wa­dzić od­po­wied­nie po­praw­ki.

Spotkanie zor­ga­ni­zo­wa­ne przez Koło Naukowe Full­Stack by­ło świet­ną okaz­ją, by oso­by nie za­zna­jo­mio­ne jesz­cze z tech­ni­ką te­stów jed­nost­ko­wych lub z jej za­sto­so­wa­niem w me­to­do­lo­gii TDD do­strzeg­ły war­tość do­da­wa­ną do pro­jek­tów in­for­ma­tycz­nych przez te­sty. Artur Dębski do­sko­na­le po­dzie­lił przy­zna­ny mu czas po­mię­dzy teorię i prak­ty­kę, naj­pierw słow­nie uza­sad­nia­jąc po­trze­bę tes­to­wa­nia w ogó­le, a za po­mo­cą TDD w szcze­gól­noś­ci, a póź­niej — de­mons­tru­jąc na ży­wo jak opi­sa­ne re­gu­ły sto­su­je się w co­dzien­nej pra­cy pro­gra­mis­ty. Szczególne bra­wa na­le­żą się mu za od­wa­gę zwią­za­ną z uży­wa­niem su­ge­ro­wa­ne­go na spot­ka­niach Koła Naukowego ję­zy­ka Java­Script, nie bę­dą­ce­go je­go pod­sta­wo­wym ję­zy­kiem.

Do wy­stą­pie­nia mia­łem je­dy­nie na­stę­pu­ją­ce, drob­ne uwa­gi, do­ty­czą­ce głów­nie bra­ku pew­nych in­for­mac­ji zwią­za­ne­go z ogra­ni­czo­nym cza­sem spot­ka­nia:

• W częś­ci teo­re­tycz­nej dość swo­bod­nie by­ły ze so­bą mie­sza­ne za­sto­so­wa­nia TDD w za­kre­sie te­stów jed­nost­ko­wych, in­te­gra­cyj­nych oraz ca­łoś­cio­wych. W przy­pad­ku każ­dej z tych ka­te­gorii TDD sto­su­je się z róż­ną trud­noś­cią. Prelegent od­niósł się do tej kwestii tyl­ko raz, stwier­dza­jąc, że te­sto­wa­nie inter­fej­su użyt­kow­ni­ka jest trud­ne.
• Poruszona zo­sta­ła kwe­stia „be­to­no­wa­nia im­ple­men­tac­ji” przez nie­właś­ci­wie za­pi­sa­ne te­sty, jed­nak pre­le­gent nie wy­jaś­nił, na czym mo­że po­le­gać „nie­właś­ci­wość”. Ta kwe­stia mog­ła­by być w za­sa­dzie te­ma­tem osob­ne­go wy­stą­pie­nia, gdyż jest bar­dzo za­wi­ła. Zjawisko „be­to­no­wa­nia im­ple­men­tac­ji” wy­stę­pu­je w wie­lu sytu­acjach, w tym przy zbyt ma­łej i – pa­ra­dok­sal­nie – zbyt du­żej licz­bie te­stów.
• Prelegent nie­co zbyt łat­wo prze­szedł do po­rząd­ku dzien­ne­go nad po­tenc­jal­ny­mi błę­da­mi wy­stę­pu­ją­cy­mi dla da­nych wej­ścio­wych nie wy­mie­nio­nych wprost w do­ku­men­cie opi­su­ją­cym wy­ma­ga­nia, a skut­ku­ją­cych na pierw­szy rzut oka błęd­nym dzia­ła­niem pod­pro­gra­mu. Takie po­dejś­cie, zgod­ne z du­chem pro­gra­mo­wa­nia eks­tre­mal­ne­go, w przy­pad­ku mo­du­łów funkcjo­nal­nych prze­twa­rza­ją­cych da­ne fi­nan­so­we lub wraż­li­we mo­że pro­wa­dzić do tra­gicz­nych skut­ków. To jed­na z war­tych wspom­nie­nia, lecz nie wy­mie­nio­nych pod­czas spot­ka­nia wad tech­ni­ki TDD: pi­sząc te­sty przed im­ple­men­tac­ją za­po­bie­ga­my co praw­da „ska­że­niu” te­stów wie­dzą o im­ple­men­tac­ji, jed­nak poz­ba­wia­my się za­ra­zem moż­li­woś­ci spraw­dze­nia po­praw­noś­ci dzia­ła­nia ko­du dla przy­pad­ków skraj­nych dla da­nej im­ple­men­tac­ji.
• Zabrakło pod­kreś­le­nia, że te­sty za­pi­sy­wa­ne zgod­nie z ideą TDD sta­no­wią bar­dzo szcze­gó­ło­wy opis kon­trak­tów po­szcze­gól­nych klas i me­tod. Odpowiednie za­sto­so­wa­nie tech­ni­ki TDD mo­że wspo­móc wdra­ża­nie kon­cep­cji Design by con­tract.

To, jak istot­nym te­ma­tem jest te­sto­wa­nie jed­nost­ko­we oraz tech­ni­ka TDD wi­dać po często­ści, z ja­ką po­ja­wia się on na wys­tą­pie­niach:

• SpreadIT 2017,
• Uszanowanko Programowanko #33: jak pro­jek­to­wać apli­kac­je.

Przy okaz­ji, pro­gra­mis­tom Java chcą­cym na­uczyć się sto­so­wa­nia tech­ni­ki te­stów jed­nost­ko­wych, w tym zgod­nie z me­to­do­lo­gia­mi TDD/TFD oraz TAD, po­le­cam książ­kę Testowa­nie apli­kac­ji Java za po­mo­cą JUnit mo­je­go autor­stwa.