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

Szukaj:

• Bezpieczeństwo
• Oprogramowanie
• Programowanie
• Testowanie

Testy jednostkowe: Tests-First Development

Jeżeli w two­rze­niu opro­gra­mo­wa­nia nie sto­su­je­cie jesz­cze tech­ni­ki te­stów jed­nost­ko­wych, go­rą­co za­chę­cam, by to zmie­nić.

Test jed­nost­ko­wy to – w skró­cie – pod­pro­gram, któ­ry we­ry­fi­ku­je po­praw­ność dzia­ła­nia jed­ne­go mo­du­łu funkcjo­nal­ne­go pro­gra­mu lub je­go ele­men­tu. Najważniej­sze ce­chy do­bre­go ze­sta­wu te­stów jed­nost­ko­wych to:

• kom­plet­ność — wy­czer­pu­je moż­li­wie sze­ro­ki za­kres przy­pad­ków da­nych wej­ścio­wych oraz sta­nu te­sto­wa­ne­go mo­du­łu, po­praw­nych i nie­po­praw­nych, a w szcze­gól­noś­ci war­toś­ci skraj­nych, le­żą­cych na po­gra­ni­czu po­praw­noś­ci,
• szyb­kość — wy­ko­nu­je się tak szyb­ko, by uru­cho­mie­nie te­stów wszyst­kich mo­du­łów ob­szer­ne­go pro­jek­tu trwa­ło naj­wy­żej kil­ka do kil­ku­na­stu se­kund,
• nie­za­leż­ność — jest nie­za­leż­ny od zew­nętrz­nych uwa­run­ko­wań, ta­kich jak po­łą­cze­nia sie­cio­we, ba­zy da­nych, zbio­ry da­nych, a tak­że moż­li­wie ma­ło za­leż­ny od in­nych mo­du­łów funkcjo­nal­nych.

Testy jed­nost­ko­we wspo­ma­ga­ją two­rze­nie opro­gra­mo­wa­nia na wie­lu eta­pach:

• pod­czas two­rze­nia mo­du­łu funkcjo­nal­ne­go po­zwa­la­ją stwier­dzić, czy mo­duł dzia­ła zgod­nie z ocze­ki­wa­nia­mi lub for­mal­ny­mi za­ło­że­nia­mi,
• pod­czas re­fak­to­ry­za­cji we­ry­fi­ku­ją po­praw­ność dzia­ła­nia mo­du­łu po wpro­wa­dze­niu zmian oraz wy­kry­wa­ją ich ewen­tu­al­ne efek­ty ubocz­ne,
• pod­czas usu­wa­nia błę­dów po­zwa­la­ją na od­two­rze­nie błę­du, stwier­dze­nie je­go po­myśl­ne­go usu­nię­cia bez efek­tów ubocz­nych i upew­nie­nie się w przy­szło­ści, że in­ne zmia­ny nie spo­wo­du­ją po­now­ne­go po­ja­wie­nia się ta­kie­go sa­me­go błę­du.

Testy jed­nost­ko­we nie mo­gą oczy­wiś­cie po­kry­wać wszyst­kich moż­li­wych wek­to­rów da­nych wej­ścio­wych i sta­nów mo­du­łów funkcjo­nal­nych. Nie by­ło­by to zresz­tą uży­tecz­ne: wy­star­czy wy­ob­ra­zić so­bie su­ma­tor liczb, któ­ry dla wie­lu mi­liar­dów kom­bi­nac­ji wej­ścio­wych bę­dzie mu­siał dzia­łać tak sa­mo do­brze, jak dla jed­nej z nich. Warto jed­nak prze­wi­dy­wać sytua­cje skraj­ne, ta­kie jak reali­zo­wa­nie dzia­łań na gra­ni­cy do­pusz­czal­nych war­toś­ci ty­pu licz­bo­we­go lub z ce­lo­wo błęd­ny­mi da­ny­mi. Czasem to, że ope­rac­ja koń­czy się zgło­sze­niem błę­du jest prze­cież po­zy­tyw­nym wy­ni­kiem te­stu, a błę­dem jest brak zgło­sze­nia sytu­acji wy­jąt­ko­wej.

Istnieje wie­le tech­nik sto­so­wa­nia te­stów jed­nost­ko­wych. Jedną z bar­dziej po­pu­lar­nych jest TTD (ang. Test-Driven Develop­ment), na­zy­wa­na też – nie­co lo­gicz­niej – TFD (ang. Tests-First Develop­ment). Tworzenie mo­du­łu funkcjo­nal­ne­go w tech­ni­ce TTD reali­zu­je się zgod­nie z na­stę­pu­ją­cą pro­ce­du­rą:

1. Określa się ze­staw wy­ma­gań funkcjo­nal­nych oraz zgod­ne z ni­mi API mo­du­łu, na przy­kład w po­sta­ci inter­fej­su kla­sy.
2. Przygoto­wu­je się zbiór te­stów po­kry­wa­ją­cych moż­li­wie sze­ro­ko przy­pad­ki po­praw­ne, nie­po­praw­ne i skraj­ne.
3. Tworzy się „pu­stą” im­ple­men­tac­ję inter­fej­sów, wy­star­cza­ją­cą by pro­gram (wraz z te­sta­mi) skom­pi­lo­wał się po­praw­nie, lecz nie reali­zu­ją­cą żad­nych czyn­no­ści. Większość te­stów oczy­wiś­cie za­koń­czy się w tym mo­men­cie nie­po­wo­dze­niem, lecz nie­ko­niecz­nie wszyst­kie: nie­któ­re „pu­ste” wy­ni­ki ope­rac­ji mo­gą być dla nie­któ­rych da­nych cał­ko­wi­cie po­praw­ne.
4. Implemen­tu­je się po­szcze­gól­ne ele­men­ty funkcjo­nal­ne tak, by za­pew­nić po­zy­tyw­ne wy­ni­ki te­stów. W mia­rę po­stę­po­wa­nia im­ple­men­tac­ji zbiór te­stów moż­na roz­sze­rzać tak, by po­kry­wać przy­pad­ki skraj­ne od­kry­wa­ne w im­ple­men­tac­ji.
5. W mo­men­cie, gdy wszyst­kie te­sty jed­nost­ko­we koń­czą się suk­ce­sem, moż­na za­ło­żyć, że mo­duł funkcjo­nal­ny jest za­im­ple­men­to­wa­ny po­praw­nie i przejść do je­go wdra­ża­nia oraz tes­to­wa­nia je­go in­te­grac­ji z in­ny­mi mo­du­ła­mi.

W teorii TFD wy­glą­da wspa­nia­le. W prak­ty­ce jed­nak po­tra­fi być kosz­mar­nie nie­prak­tycz­ne:

• ilość ko­du zwią­za­ne­go z te­sta­mi zna­czą­co prze­wyż­sza ilość ko­du te­sto­wa­ne­go,
• uzys­ka­nie wy­star­cza­ją­ce­go po­kry­cia cha­rak­te­rys­tycz­nych przy­pad­ków te­sto­wych jest bar­dzo trud­ne,
• ist­nie­nie ob­szer­ne­go zbio­ru te­stów znie­chę­ca do prze­pro­wa­dza­nia po­waż­nej re­fak­to­ry­za­cji mo­du­łu, zwią­za­nej ze zmia­ną API lub algo­ryt­mów.

Alterna­tyw­ne, bar­dziej prak­tycz­ne po­dej­ścia do sto­so­wa­nia te­stów jed­nost­ko­wych przed­sta­wię w ko­lej­nych wpi­sach z tej se­rii.