{"id":10899,"date":"2021-07-07T23:32:58","date_gmt":"2021-07-07T21:32:58","guid":{"rendered":"https:\/\/sii.pl\/blog\/?p=10899"},"modified":"2023-10-27T17:40:50","modified_gmt":"2023-10-27T15:40:50","slug":"abap-unit-i-test-driven-development","status":"publish","type":"post","link":"https:\/\/sii.pl\/blog\/abap-unit-i-test-driven-development\/","title":{"rendered":"ABAP Unit i Test-driven Development"},"content":{"rendered":"\n

Zmiany wprowadzane w tradycyjnych programach cz\u0119sto psuj\u0105 ich funkcjonalno\u015b\u0107, powoduj\u0105c przy tym ogromne szkody w dzia\u0142alno\u015bci ca\u0142ego systemu. <\/p>\n\n\n\n

Chc\u0105c unikn\u0105\u0107 takiej sytuacji, nale\u017cy wykorzystywa\u0107 rozw\u00f3j oparty na testach (TDD \u2013 ang. Test-driven Development) dzi\u0119ki narz\u0119dziu ABAP Unit. W tym artykule wyja\u015bni\u0119, czym jest TDD i jak je wdro\u017cy\u0107 w ABAP-ie.<\/p>\n\n\n\n

W tradycyjnym procesie programistycznym po stworzeniu nowego programu lub zmianie istniej\u0105cego nast\u0119pnym krokiem jest wykonanie podstawowych test\u00f3w. W rzeczywisto\u015bci jednak cz\u0119sto brakuje czasu na ten etap prac i jest on pomijany, cz\u0119sto z katastrofalnymi skutkami. Przeciwie\u0144stwem takiego procesu jest TDD, polegaj\u0105cy na pisaniu test\u00f3w przed utworzeniem nowej funkcjonalno\u015bci b\u0105d\u017a zmiany istniej\u0105cej.<\/p>\n\n\n\n

W artykule skupi\u0119 si\u0119 na dzia\u0142aniu framework\u2019a ABAP Unit i na tym, jak dodawa\u0107 testy jednostkowe do istniej\u0105cego kodu, czy to proceduralnego czy obiektowego. Programi\u015bci, kt\u00f3rzy pisz\u0105 nowy kod lub tworz\u0105 zmiany w kodzie istniej\u0105cym, powinni zacz\u0105\u0107 swoj\u0105 prac\u0119 od napisania testu jednostkowego przed dokonaniem zmian w kodzie. Mo\u017ce to si\u0119 wydawa\u0107 dziwne, poniewa\u017c tworzysz test jednostkowy do kodu, kt\u00f3ry jeszcze nie istnieje. Ale o to w\u0142a\u015bnie chodzi. Najpierw udowadniasz, \u017ce napisany kod nie robi tego co tak naprawd\u0119 powinien, poprzez napisanie testu jednostkowego. Nast\u0119pnie tworzysz kod, a\u017c w 100% b\u0119dziesz pewny, \u017ce problem zosta\u0142 rozwi\u0105zany.<\/p>\n\n\n\n

W normalnym procesie developmentu piszesz kod, aby rozwi\u0105za\u0107 problem i dop\u00f3ki nie zrobisz testu r\u0119cznego, nie jeste\u015b w 100% pewien czy napisa\u0142e\u015b kod poprawnie, czy te\u017c nie. TDD zapobiega takiej sytuacji przebiegaj\u0105c wed\u0142ug okre\u015blonego cyklu:<\/p>\n\n\n\n

    \n
  1. Napisanie przypadku testowego.
    <\/strong>Na tym etapie powinni\u015bmy wiedzie\u0107, co chcemy przetestowa\u0107 i czego oczekujemy od testowanego funkcjonalno\u015bci.<\/li>\n\n\n\n
  2. Uruchomienie napisanego testu.
    <\/strong>Uruchomienie testu i oczekiwanie na b\u0142\u0105d kompilacji, poniewa\u017c nie istnieje kod, kt\u00f3ry chcemy testowa\u0107.<\/li>\n\n\n\n
  3. Napisanie minimalnego kodu.
    <\/strong>Stworzenie minimalnego kodu odpowiedzialnego za funkcjonalno\u015b\u0107, dzi\u0119ki kt\u00f3remu po uruchomieniu testu przejdzie w stan \u201ezielony\u201d.<\/li>\n\n\n\n
  4. Refaktoryzacja napisanego kodu.
    <\/strong>Przeprowadzamy refaktoryzacj\u0119 kodu produkcyjnego i kodu testowego.<\/li>\n\n\n\n
  5. Uruchomienie wszystkich test\u00f3w.
    <\/strong>Cykl TDD si\u0119 zamyka i powtarzamy go, dop\u00f3ki nie napiszemy wszystkich test\u00f3w pokrywaj\u0105cych logik\u0119 biznesow\u0105.<\/li>\n<\/ol>\n\n\n\n

    Definicja klasy testowej<\/h2>\n\n\n\n

    Aby zdefiniowa\u0107 klas\u0119 testow\u0105, musisz najpierw mie\u0107 zdefiniowan\u0105 klas\u0119 globaln\u0105, u\u017cywaj\u0105c do tego transakcji SE24 albo SE80. Po stworzeniu klasy globalnej przejd\u017a do menu: Skok do \u2192 Lokalne definicje\/implementacje \u2192 Lokalne klasy testowe <\/strong>(z ang. Goto \u2192 <\/strong> Local Definitions\/Implementations \u2192 <\/strong>Local Test Class).<\/p>\n\n\n\n

    W klasie testowej musisz zdefiniowa\u0107 kilka rzeczy:<\/p>\n\n\n\n

      \n
    1. W\u0142\u0105czenie testowania prywatnych metod.<\/li>\n\n\n\n
    2. Ustalenie og\u00f3lnych ustawie\u0144 definicji klasy testowej.<\/li>\n\n\n\n
    3. Deklaracja definicji danych.<\/li>\n\n\n\n
    4. Konfiguracja test\u00f3w jednostkowych.<\/li>\n\n\n\n
    5. Definicja rzeczywistych metod testowania.<\/li>\n\n\n\n
    6. Implementacja metod pomocniczych.<\/li>\n<\/ol>\n\n\n\n

      W\u0142\u0105czenie testowania prywatnych metod<\/h2>\n\n\n\n

      Aby w\u0142\u0105czy\u0107 testowanie prywatnych metod nale\u017cy doda\u0107 nast\u0119puj\u0105cy kod:<\/p>\n\n\n\n

      \"fragment<\/a><\/figure>\n\n\n\n

      W powy\u017cszym przyk\u0142adzie klasa ZCL_RANGE<\/strong> jest klas\u0105 globaln\u0105, kt\u00f3r\u0105 b\u0119dzie testowana przez lokaln\u0105 klas\u0119 LCL_RANGE_TEST_CLASS. <\/strong>W\u0142\u0105czenie funkcjonalno\u015bci testowania metod prywatnych odbywa si\u0119 za po\u015brednictwem s\u0142\u00f3w kluczowych LOCAL FRIENDS<\/strong> nazwa_klasy_testowej<\/em><\/strong>.<\/p>\n\n\n\n

      Ustalenie og\u00f3lnych ustawie\u0144 definicji klasy testowej<\/h2>\n\n\n\n

      Pierwsza linijka m\u00f3wi, \u017ce jest to klasa testowa. Nast\u0119pnie definiujemy RISK LEVEL (poziom ryzyka) \u2013 rozr\u00f3\u017cniane
      s\u0105 trzy: CRITICAL, DANGEROUS i HARMLESS. Ostatni\u0105 w\u0142a\u015bciwo\u015bci\u0105 jest DURATION (czas trwania testu), gdzie do wyboru s\u0105 trzy poziomy: LONG, MEDIUM oraz SHORT.<\/p>\n\n\n\n

      \"fragment<\/a><\/figure>\n\n\n\n
      <\/div>\n\n\n\n

      Deklaracja definicji danych<\/h2>\n\n\n\n

      Kontynuuj\u0105c definicj\u0119 klasy testowej dochodzimy do deklaracji danych. Pierwsz\u0105 i najwa\u017cniejsz\u0105 zmienn\u0105 jak\u0105 deklarujemy jest zmienna do przechowywania instancji klasy, kt\u00f3ra jest testowana.<\/p>\n\n\n\n

      \"fragment<\/a><\/figure>\n\n\n\n
      <\/div>\n\n\n\n

      Definicja metody SETUP<\/h2>\n\n\n\n

      Pierwsz\u0105 metod\u0105, kt\u00f3r\u0105 nale\u017cy zawsze zdefiniowa\u0107 jest prywatna metoda SETUP<\/strong>. Odpowiedzialna jest za resetowanie stanu systemu, tak aby ka\u017cda metoda testowa zachowywa\u0142a si\u0119 jakby by\u0142a pierwsz\u0105 uruchomion\u0105 metod\u0105 testow\u0105. Dlatego ka\u017cda z globalnych zmiennych musi zosta\u0107 wyczyszczona lub ustawiona na okre\u015blon\u0105 warto\u015b\u0107, a testowana klasa musi zosta\u0107 utworzona od nowa. Pozwala to unikn\u0105\u0107 tzw. sprz\u0119\u017cenia czasowego (wynik jednego testu mo\u017ce mie\u0107 wp\u0142yw na wynik drugiego testu).<\/p>\n\n\n\n

      \"fragment<\/a><\/figure>\n\n\n\n
      <\/div>\n\n\n\n

      Definicja rzeczywistych metod testowania<\/h2>\n\n\n\n

      Po definicji metody SETUP nast\u0119pnym krokiem jest definicja rzeczywistych metod testowania. S\u0142owa kluczowe FOR TESTING<\/strong> po nazwie metody informuj\u0105, \u017ce ta metoda b\u0119dzie uruchamiana za ka\u017cdym razem, kiedy programista uruchomi test.<\/p>\n\n\n\n

      \"fragment<\/a><\/figure>\n\n\n\n
      <\/div>\n\n\n\n

      Implementacja metod pomocniczych<\/h2>\n\n\n\n

      Ostatnim krokiem jest implementacja metod pomocniczych (bez s\u0142\u00f3w kluczowych FOR TESTING<\/strong>).
      S\u0105 to zwyczajne metody prywatne wywo\u0142ywane przez metody testowe. Celem metod pomocniczych jest wykonanie zada\u0144 ni\u017cszego poziomu dla jednej lub wi\u0119cej metod testowych.<\/p>\n\n\n\n

      \"fragment<\/a><\/figure>\n\n\n\n
      <\/div>\n\n\n\n
      \"fragment<\/a><\/figure>\n\n\n\n
      <\/div>\n\n\n\n

      Struktura GIVEN\/WHEN\/THEN<\/h2>\n\n\n\n

      Kod metody testuj\u0105cej powinien by\u0107 napisany we wzorcu GIVEN\/WHEN\/THEN. GIVEN opisuje stan tu\u017c przed testem, kt\u00f3ry ma zosta\u0107 wykonany. W tej sekcji r\u00f3wnie\u017c okre\u015blane s\u0105 parametry wej\u015bciowe testu. W sekcji WHEN testowana jest funkcjonalno\u015b\u0107. W ostatniej cz\u0119\u015bci THEN sprawdzane s\u0105 warunki (wywo\u0142ywane metody ASSERT).<\/p>\n\n\n\n

      \"fragment<\/a><\/figure>\n\n\n\n
      <\/div>\n\n\n\n

      Test Doubles<\/h2>\n\n\n\n

      Za\u0142o\u017ceniem Test Doubles jest podmieni\u0107 w trakcie trwania test\u00f3w zale\u017cno\u015bci testowanej klasy czym\u015b, nad czym mamy pe\u0142n\u0105 kontrol\u0119. Warto zdecydowa\u0107 si\u0119 na taki manewr w momencie, gdy nie mo\u017cemy (albo z jaki\u015b powod\u00f3w nie chcemy) skorzysta\u0107 z prawdziwych zale\u017cno\u015bci (w obiekcie zale\u017cnym \u201edu\u017co si\u0119 dzieje\u201d\/posiada skomplikowan\u0105 logik\u0119). Tak naprawd\u0119 te zale\u017cno\u015bci s\u0105 w rzeczywisto\u015bci nieszkodliwymi duplikatami wykorzystywanymi tylko i wy\u0142\u0105cznie do cel\u00f3w testowych.<\/p>\n\n\n\n

      Kiedy m\u00f3wimy o testowaniu podw\u00f3jnym u\u017cywamy termin\u00f3w: stub, spy, mock object, dummy object, fake object. S\u0105 to rodzaje Test Doubles, kt\u00f3re s\u0105 wykorzystywane w zale\u017cno\u015bci od potrzeb.<\/p>\n\n\n\n

        \n
      1. Stub<\/strong> \u2013 wykorzystywany jest w sytuacji, kiedy obiekt klasy testowej jest zale\u017cny od zwracanych parametr\u00f3w przez metod\u0119 obiektu dublowanego.<\/li>\n\n\n\n
      2. Spy<\/strong> \u2013 wykorzystywany jest w sytuacji, kiedy chcemy mie\u0107 pewno\u015b\u0107, \u017ce dana metoda innego obiektu zosta\u0142a wywo\u0142ana przez klas\u0119 testow\u0105 z oczekiwanymi parametrami, nie spodziewaj\u0105c si\u0119 odpowiedzi. Jest to tzw. punkt obserwacyjny, kt\u00f3ry weryfikuje nasze za\u0142o\u017cenia.<\/li>\n\n\n\n
      3. Mock Object<\/strong> \u2013 wykorzystujemy ten typ, gdy zale\u017cy nam na konkretnej odpowiedzi w przypadku otrzymania konkretnych warto\u015bci.<\/li>\n\n\n\n
      4. Fake Object<\/strong> \u2013 dublowane obiekty, kt\u00f3re zawieraj\u0105 mniej skomplikowana logik\u0119 biznesow\u0105 w por\u00f3wnaniu do oryginalnych obiekt\u00f3w.<\/li>\n\n\n\n
      5. Dummy Object<\/strong> \u2013 wykorzystywane w sytuacji, kiedy chcemy przekaza\u0107 sam\u0105 instancj\u0119 obiektu.<\/li>\n<\/ol>\n\n\n\n

        Implementacja Test Doubles<\/h2>\n\n\n\n

        Na potrzeby przyk\u0142adu stworzy\u0142em dwie klasy oraz jeden interfejs, kt\u00f3ry jest odpowiedzialny za pobieranie aktualnego kursu walut. U\u017cytkownik podaje walut\u0119 \u017ar\u00f3d\u0142owa i docelow\u0105, a interfejs zwraca odpowiedni kurs. Pierwsza klasa jest odwzorowaniem banknotu. Zawiera w sobie dwa atrybuty AMOUNT<\/strong> i CURRENCY<\/strong> oraz metody GET dla tych atrybut\u00f3w. Druga klasa jest odwzorowaniem portfela. Zawiera atrybuty BANKNOTE<\/strong> i RATE_PROVIDER<\/strong> oraz metody: ADD_BANKNOTE<\/strong>, SET_RATE_PROVIDER<\/strong> oraz GET_AMOUNT<\/strong>. Stworzy\u0142em klas\u0119 testow\u0105 o nast\u0119puj\u0105cej definicji oraz implementacji.<\/p>\n\n\n\n

        \"fragment<\/a><\/figure>\n\n\n\n
        <\/div>\n\n\n\n
        \"fragment<\/a><\/figure>\n\n\n\n

        Aby test klasy ZCL_DEMO_WALLET<\/strong> zosta\u0142 poprawnie napisany musia\u0142em wykorzysta\u0107 Test Doubles. Stworzy\u0142em instancj\u0119 obiektu dublowanego, kt\u00f3ry implementuje interfejs ZIF_DEMO_RATE_PROVIDER<\/strong> (linia 29). W naszym przyk\u0142adzie metod\u0105 do dublowania b\u0119dzie GET_CURRENCY_RATE<\/strong>. Mo\u017ce si\u0119 to wydawa\u0107 dziwne, ale na pocz\u0105tku nie wywo\u0142ujemy tej metody, lecz ustawiamy warto\u015b\u0107 jak\u0105 ona zwr\u00f3ci, a nast\u0119pnie jest ona wywo\u0142ywana (linie 30-33).<\/p>\n\n\n\n

        W te\u015bcie wykorzysta\u0142em stub-a, poniewa\u017c zwracana warto\u015b\u0107 przez metod\u0119 GET_TOTAL_AMOUNT <\/strong>jest zale\u017cna od obiektu RATE_PROVIDER<\/strong>. Je\u015bli testy zosta\u0142y wykonane prawid\u0142owo, w\u00f3wczas powinny by\u0107 oznaczone na zielono. Na poni\u017cszym obrazku znajduje si\u0119 wynik testu:<\/p>\n\n\n\n

        \"\"<\/a><\/figure>\n\n\n\n
        <\/div>\n\n\n\n

        Uruchamianie test\u00f3w jednostkowych<\/h2>\n\n\n\n

        Aby uruchomi\u0107 testy jednostkowe, nale\u017cy przej\u015b\u0107 do transakcji SE80. Nast\u0119pnie nale\u017cy odnale\u017a\u0107 testowan\u0105 klas\u0119 oraz klikn\u0105\u0107 na niej PPM i wybra\u0107: Wykonanie -> Testy modu\u0142owe z -> Pomiar pokrycia:<\/strong><\/p>\n\n\n\n

        \"\"<\/a><\/figure>\n\n\n\n
        <\/div>\n\n\n\n

        Podsumowanie<\/h2>\n\n\n\n

        Testowanie jednostkowe wcale nie jest \u0142atwe, wr\u0119cz przeciwnie. U\u017cywaj\u0105c funkcjonalno\u015bci
        z pe\u0142nym pokryciem testowym i korzystaj\u0105c z metodologii TDD przy ich tworzeniu, mamy du\u017c\u0105 lepsz\u0105 kontrol\u0119 nad utrzymaniem i rozwojem kodu. Wprowadzaj\u0105c dowolne zmiany czy przeprowadzaj\u0105c refaktoryzacj\u0119 kodu, w ci\u0105gu kilku sekund dowiesz si\u0119, czy zepsu\u0142e\u015b jak\u0105kolwiek istniej\u0105c\u0105 funkcjonalno\u015b\u0107. Kiedy zaczniesz korzysta\u0107 z TDD, przekonasz si\u0119, \u017ce cykl ten przebiega w kilku krokach. Musisz jedynie po\u015bwi\u0119ci\u0107 troch\u0119 czasu i nabra\u0107 wprawy, a w przysz\u0142o\u015bci testy jednostkowe stan\u0105 si\u0119 nieodzownym elementem Twojej pracy.<\/p>\n\n\n

        \n \n
        \n \n
        \n
        \n \n\n
        <\/div>\n <\/div>\n
        \n \n\n
        <\/div>\n <\/div>\n
        \n \n\n
        <\/div>\n <\/div>\n
        \n \n\n
        <\/div>\n <\/div>\n
        \n \n\n
        <\/div>\n <\/div>\n <\/div>\n \n
        \n
        \n \n\n
        <\/div>\n <\/div>\n
        \n \n\n
        <\/div>\n <\/div>\n
        \n \n\n
        <\/div>\n <\/div>\n
        \n \n\n
        <\/div>\n <\/div>\n
        \n \n\n
        <\/div>\n <\/div>\n <\/div>\n<\/div>\n \n\n
        \n 5\/5 ( vote: 1) <\/div>\n <\/div>\n","protected":false},"excerpt":{"rendered":"

        Zmiany wprowadzane w tradycyjnych programach cz\u0119sto psuj\u0105 ich funkcjonalno\u015b\u0107, powoduj\u0105c przy tym ogromne szkody w dzia\u0142alno\u015bci ca\u0142ego systemu. Chc\u0105c unikn\u0105\u0107 … Continued<\/a><\/p>\n","protected":false},"author":294,"featured_media":11004,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_editorskit_title_hidden":false,"_editorskit_reading_time":0,"_editorskit_is_block_options_detached":false,"_editorskit_block_options_position":"{}","inline_featured_image":false,"footnotes":""},"categories":[1314],"tags":[860,174,811],"class_list":["post-10899","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development-na-twardo","tag-abap-unit","tag-erp","tag-sap-abap"],"acf":[],"aioseo_notices":[],"republish_history":[],"featured_media_url":"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/06\/grafika.png","category_names":["Development na twardo"],"_links":{"self":[{"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/posts\/10899"}],"collection":[{"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/users\/294"}],"replies":[{"embeddable":true,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/comments?post=10899"}],"version-history":[{"count":2,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/posts\/10899\/revisions"}],"predecessor-version":[{"id":25297,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/posts\/10899\/revisions\/25297"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/media\/11004"}],"wp:attachment":[{"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/media?parent=10899"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/categories?post=10899"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/tags?post=10899"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}