{"id":551,"date":"2022-01-26T01:34:13","date_gmt":"2022-01-26T01:34:13","guid":{"rendered":"https:\/\/www.cybermedian.com\/pl\/?p=551"},"modified":"2025-02-17T11:39:57","modified_gmt":"2025-02-17T03:39:57","slug":"test-drive-development-approach-for-agile-software-development","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/pl\/test-drive-development-approach-for-agile-software-development\/","title":{"rendered":"Podej\u015bcie do rozwoju opartego na testach w zwinnej produkcji oprogramowania"},"content":{"rendered":"
\n
\n
\n

Teraz ludzie cz\u0119sto m\u00f3wi\u0105 o zwinnej produkcji.<\/p>\n

Czym jest zwinny rozw\u00f3j?<\/h4>\n

Zwinny rozw\u00f3j<\/a> jest zdolno\u015bci\u0105 do rozwoju oprogramowania, kt\u00f3ra odpowiada na szybko zmieniaj\u0105ce si\u0119 potrzeby. Ich konkretne nazwy, koncepcje, procesy i terminologia r\u00f3\u017cni\u0105 si\u0119. W por\u00f3wnaniu do \u201eniezwinny<\/a>,\u201d k\u0142ad\u0105 nacisk na blisk\u0105 wsp\u00f3\u0142prac\u0119 mi\u0119dzy zespo\u0142ami programist\u00f3w a ekspertami biznesowymi, komunikacj\u0119 twarz\u0105 w twarz (uznawan\u0105 za bardziej efektywn\u0105 ni\u017c dokumentacja pisemna) oraz cz\u0119ste dostarczanie nowych wersji oprogramowania, ma\u0142ych i zespo\u0142y samoorganizuj\u0105ce si\u0119<\/a> do pisania ma\u0142ych i warto\u015bciowych funkcji oraz podej\u015b\u0107 do organizacji zespo\u0142u, kt\u00f3re dostosowuj\u0105 si\u0119 do zmieniaj\u0105cych si\u0119 potrzeb, z wi\u0119kszym naciskiem na rol\u0119 ludzi w rozwoju oprogramowania.<\/p>\n

Jednak istnieje kilka podobnych wersji metod rozwoju zwinnego TDD, takich jak TDD: BDD, DDD i ATDD. Pozw\u00f3l, \u017ce kr\u00f3tko przedstawi\u0119 te metody, zanim szczeg\u00f3\u0142owo om\u00f3wi\u0119 TDD:<\/p>\n

TDD: Rozw\u00f3j oparty na testach<\/strong><\/p>\n

Rozw\u00f3j oparty na testach<\/a> (TDD) to proces rozwoju oprogramowania, kt\u00f3ry polega na przekszta\u0142caniu wymaga\u0144 oprogramowania w przypadki testowe przed ca\u0142kowitym opracowaniem oprogramowania oraz \u015bledzeniu ca\u0142ego rozwoju oprogramowania poprzez wielokrotne testowanie oprogramowania dla wszystkich przypadk\u00f3w testowych. To jest przeciwie\u0144stwo rozwijania oprogramowania najpierw, a nast\u0119pnie tworzenia przypadk\u00f3w testowych. Niekt\u00f3re popularne modele bardzo dobrze wspieraj\u0105 TDD, takie jak MVC i MVP<\/a>.<\/p>\n

<\/figure>\n

BDD: Rozw\u00f3j oparty na zachowaniu (Behavior Driven Development)<\/strong><\/p>\n

Rozw\u00f3j oparty na zachowaniu (BDD) to r\u00f3wnie\u017c zwinny proces rozwoju oprogramowania. Zach\u0119ca do wsp\u00f3\u0142pracy mi\u0119dzy programistami, testerami zapewnienia jako\u015bci i przedstawicielami klient\u00f3w w projektach oprogramowania. Zach\u0119ca zespo\u0142y do korzystania z rozm\u00f3w i konkretnych przyk\u0142ad\u00f3w, aby sformalizowa\u0107 wsp\u00f3lne zrozumienie, jak aplikacja powinna dzia\u0142a\u0107. Pochodzi z rozwoju opartego na testach (TDD).<\/p>\n

<\/figure>\n

ATDD: Rozw\u00f3j oparty na testach akceptacyjnych<\/strong><\/p>\n

Aby promowa\u0107 realizacj\u0119 funkcjonalnego kodu poprzez przypadki testowe jednostkowe, zesp\u00f3\u0142 musi zdefiniowa\u0107 oczekiwane standardy jako\u015bci i zasady akceptacji oraz promowa\u0107 praktyk\u0119 TDD programist\u00f3w i wydajno\u015b\u0107 tester\u00f3w poprzez jasny i sp\u00f3jny plan test\u00f3w akceptacyjnych (w tym seri\u0119 scenariuszy testowych). Dla programist\u00f3w k\u0142adzie nacisk na to, jak wdro\u017cy\u0107 system i jak go testowa\u0107.<\/p>\n

<\/figure>\n

DDD: Projektowanie oparte na domenie<\/strong><\/p>\n

DDD odnosi si\u0119 do projektowania opartego na domenie, tj. rozwoju opartego na domenie. DDD jest w rzeczywisto\u015bci zbudowane na tym fundamencie, poniewa\u017c koncentruje si\u0119 na projektowaniu warstwy us\u0142ug, skupia si\u0119 na wdro\u017ceniu biznesowym, \u0142\u0105czy analityk\u0119 i projektowanie oraz nie utrzymuje tego w podzielonym stanie, aby poprawnie i kompleksowo wdro\u017cy\u0107 potrzeby klient\u00f3w i zbudowa\u0107 model skalowalno\u015bci biznesu.<\/p>\n

<\/figure>\n

Plan wdro\u017cenia TDD<\/h3>\n
\n

Poprzez testowanie promujemy ca\u0142y rozw\u00f3j, ale rozw\u00f3j oparty na testach to nie tylko prosta praca testowa, ale proces kwantyfikacji analizy wymaga\u0144, projektowania i kontroli jako\u015bci.<\/em><\/p>\n<\/blockquote>\n

Zasady rozwoju<\/strong><\/p>\n

\n

Najpierw napisz kod testowy, a nast\u0119pnie napisz kod funkcji.<\/em><\/p>\n<\/blockquote>\n

    \n
  1. Napisz kod testowy zgodnie z dokumentem wymaga\u0144, a nie w celu zrealizowania funkcji;<\/li>\n
  2. Nie chciej by\u0107 gruby jednym k\u0119sem. Podczas testowania du\u017cych blok\u00f3w funkcjonalnych, najpierw powiniene\u015b podzieli\u0107 je na mniejsze bloki funkcjonalne do testowania;<\/li>\n
  3. Pami\u0119taj, aby nie pisa\u0107 kodu w celu uko\u0144czenia funkcji, u\u017cyj najprostszego mo\u017cliwego kodu do wdro\u017cenia funkcji;<\/li>\n
  4. Je\u015bli wymagania mog\u0105 by\u0107 testowane, napisz kod testowy i zrezygnuj z tych, kt\u00f3re nie mog\u0105 by\u0107 testowane lub uwa\u017casz, \u017ce nie musz\u0105 by\u0107 testowane;<\/li>\n
  5. Przed zmian\u0105\/dodaniem jakiegokolwiek kodu funkcji, musisz najpierw pomy\u015ble\u0107, czy chcesz zmieni\u0107\/doda\u0107 przypadki testowe;<\/li>\n
  6. Kod funkcji\/testu, nierozs\u0105dna struktura, zduplikowany kod itp., refaktoryzuj na czas po przej\u015bciu testu.<\/li>\n<\/ol>\n

    Proces rozwoju TDD<\/strong><\/p>\n

      \n
    1. Analizuj i okre\u015bl docelowy scenariusz testowy;<\/li>\n
    2. Dodaj test jednostkowy, aby zweryfikowa\u0107 wej\u015bcie i wyj\u015bcie scenariusza testowego;<\/li>\n
    3. Uruchom test i uzyskaj wynik nieudanego testu;<\/li>\n
    4. Napisz najprostszy kod funkcji, aby przej\u015b\u0107 test;<\/li>\n
    5. Uruchom test ponownie i zobacz, \u017ce test przeszed\u0142;<\/li>\n
    6. Przeprowad\u017a refaktoryzacj\u0119 kodu, w tym kodu funkcjonalnego i kodu testu jednostkowego;<\/li>\n
    7. Powtarzaj powy\u017csze kroki, a\u017c rozw\u00f3j zostanie zako\u0144czony.<\/li>\n<\/ol>\n

      Korzy\u015bci z TDD<\/strong><\/p>\n

        \n
      1. Zmniejsz obci\u0105\u017cenie programist\u00f3w<\/strong>. Dzi\u0119ki jasnemu procesowi skupmy si\u0119 tylko na jednym punkcie na raz, a obci\u0105\u017cenie my\u015blenia jest mniejsze.<\/li>\n
      2. Sie\u0107 ochronna<\/strong>. Pe\u0142ne testowanie jednostkowe zapewnia sie\u0107 ochronn\u0105 dla kodu produktu, co u\u0142atwia dostosowanie si\u0119 do zmian w wymaganiach lub popraw\u0119 projektu kodu. Wi\u0119c je\u015bli wymagania twojego projektu s\u0105 stabilne, zrealizowane za jednym razem i nie ma p\u00f3\u017aniejszych zmian, korzy\u015bci z TDD s\u0105 mniejsze.<\/li>\n
      3. Wyja\u015bnij wymagania z wyprzedzeniem<\/strong>. Pisanie test\u00f3w najpierw mo\u017ce pom\u00f3c nam pomy\u015ble\u0107 o wymaganiach i wyja\u015bni\u0107 szczeg\u00f3\u0142y wymaga\u0144 z wyprzedzeniem, zamiast odkrywa\u0107 niejasne wymagania dopiero w po\u0142owie kodu.<\/li>\n
      4. Szybka informacja zwrotna<\/strong>. Wiele os\u00f3b m\u00f3wi, \u017ce podczas TDD moja obj\u0119to\u015b\u0107 kodu wzrasta, wi\u0119c wydajno\u015b\u0107 rozwoju maleje. Jednak je\u015bli nie masz test\u00f3w jednostkowych, musisz testowa\u0107 je r\u0119cznie, sp\u0119dzasz du\u017co czasu na przygotowywaniu danych, uruchamianiu aplikacji, modyfikowaniu interfejs\u00f3w itp., a informacja zwrotna jest wolna. Dok\u0142adniej m\u00f3wi\u0105c, szybka informacja zwrotna to korzy\u015b\u0107 z testowania jednostkowego.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n<\/section>\n
        \n
        \n
        \n<\/div>\n
        \n
        \n

        Zasady Agile i Scrum<\/h4>\n