{"id":594,"date":"2023-11-08T11:23:25","date_gmt":"2023-11-08T10:23:25","guid":{"rendered":"https:\/\/klaudia-bernat.profesjonalnyprogramista.pl\/?p=594"},"modified":"2024-01-16T11:40:14","modified_gmt":"2024-01-16T10:40:14","slug":"test-driven-development","status":"publish","type":"post","link":"https:\/\/klaudia-bernat.profesjonalnyprogramista.pl\/?p=594","title":{"rendered":"Test-Driven Development"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t\t\t

\n\t\tTest Driven-Development\t<\/h2>\n\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Co to jest?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Jest to technika pisania oprogramowania, w kt\u00f3rej g\u0142\u00f3wn\u0105 ide\u0105 jest pisanie testu unitowego do funkcjonalno\u015bci, kt\u00f3ra jeszcze nie istnieje, a dopiero potem napisanie kodu implementuj\u0105cego t\u0105 funkcjonalno\u015b\u0107.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Spis tre\u015bci<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
  1. Dlaczego testujemy kod?<\/a><\/li>
  2. Regu\u0142y<\/a><\/li>
  3. Testy unitowe – cechy dobrych test\u00f3w<\/a><\/li>
  4. Kiedy NIE u\u017cywamy?<\/a><\/li>
  5. Wady TDD<\/a><\/li>
  6. Przyk\u0142ad<\/a><\/li>
  7. Podsumowanie<\/a><\/li><\/ol>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t\t
    \n\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t

    Dlaczego testujemy kod?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t
    • Dzi\u0119ki testom kod staje si\u0119 \u0142atwiejszy do zrozumienia<\/li>
    • \u0141atwiej jest wprowadza\u0107 zmiany w kodzie<\/li>
    • Mo\u017cna w\u0142\u0105cza\u0107 testy automatyczne<\/li>
    • Sprawia, \u017ce odnajdujemy b\u0142\u0119dy w momencie pisania danej funkcjonalno\u015bci. Odnajdywanie b\u0142\u0119d\u00f3w p\u00f3\u017aniej jest bardzo trudne, a im p\u00f3\u017aniej, tym jest gorzej<\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
      \n\t\t\t\t\t\t
      \n\t\t\t\t\t
      \n\t\t\t
      \n\t\t\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t

      Regu\u0142y<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t
      1. Faza RED – „Nie mo\u017cesz napisa\u0107 \u017cadnego produkcyjnego kodu, dop\u00f3ki nie b\u0119dziesz mia\u0142 nie przechodz\u0105cego testu.”
        • Najpierw trzeba wymy\u015bli\u0107 jak\u0105 chcemy doda\u0107 funkcjonalno\u015b\u0107<\/li>
        • Piszemy tylko ma\u0142e testy w plikach testowych i badamy ma\u0142y kawa\u0142ek funkcjonalno\u015bci<\/li>
        • Upewniamy si\u0119, \u017ce test nie przechodzi<\/li><\/ul><\/li>
        • Faza GREEN – „Nie mo\u017cesz napisa\u0107wi\u0119cej testu, je\u017celi ten test nie przechodzi. B\u0142\u0105d kompilacji jest nie dzia\u0142aj\u0105cym testem.”
          • Piszemy tylko w kodzie produkcyjnym<\/li>
          • Naszym celem jest, \u017ceby wszystkie testy przechodzi\u0142y i by\u0142y zielone<\/li>
          • Kod ma by\u0107 funkcjonalny, a nie „pi\u0119kny”<\/li>
          • Testy puszczamy tak szybko jak to tylko mo\u017cliwe<\/li><\/ul><\/li>
          • Faza REFACTOR – „Nie mo\u017cesz napisa\u0107 wi\u0119cej kodu produkcyjnego ni\u017c ten wymagany do przej\u015bcia obecnego testu.”
            • Refaktorujemy kod<\/li>
            • Nie dodajemy nowych funkcjonalno\u015bci<\/li>
            • Nie mo\u017cemy tym popsu\u0107 test\u00f3w, musz\u0105 przechodzi\u0107<\/li><\/ul><\/li><\/ol>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
              \n\t\t\t\t
              \n\t\t\t\t\t\t\t\t\t

              Inaczej mo\u017cna to przeza\u0107 za pomoc\u0105 schematu Red Green Refactor<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

              \n\t\t\t\t
              \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
              \n\t\t\t\t
              \n\t\t\t\t\t

              Wnioski z schematu?<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
              \n\t\t\t\t
              \n\t\t\t\t\t\t\t\t\t
              • Nale\u017cy po\u015bwi\u0119ci\u0107 tyle samo czasu na ka\u017cdy z tych etap\u00f3w<\/li>
              • Zawsze powinni\u015bmy zrobi\u0107 refaktor, nie mo\u017cna go pomija\u0107<\/li>
              • Oddzielamy rozwi\u0105zywanie problemu od tworzenia architektury kodu<\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                \n\t\t\t\t\t\t
                \n\t\t\t\t\t
                \n\t\t\t
                \n\t\t\t\t\t\t
                \n\t\t\t\t
                \n\t\t\t\t\t

                Testy unitowe - cechy dobrych test\u00f3w<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                \n\t\t\t\t
                \n\t\t\t\t\t\t\t\t\t
                • Testuj\u0105 jedn\u0105 funkcjonalno\u015b\u0107 – oboj\u0119tnie, czy to metoda, klasa, czy paczka<\/li>
                • Powinny dzia\u0142a\u0107 w izolacji – test powinien przechodzi\u0107 lub nie przechodzi\u0107 niezale\u017cnie od innych test\u00f3w<\/li>
                • S\u0105 powtarzalne<\/li>
                • Nazwa testu m\u00f3wi nam co on robi<\/li>
                • Testuj\u0105 zachowanie, ale nie detale implementacyjne<\/li>
                • Powinny by\u0107 napisane tak, \u017ceby tylko na ich podstawie da\u0142o si\u0119 odbudowa\u0107 ca\u0142y system<\/li>
                • Nie pokazuj\u0105 bug\u00f3w w kodzie<\/li>
                • Nie testuj\u0105 metod prywatnych bezpo\u015brednio<\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                  \n\t\t\t\t\t\t
                  \n\t\t\t\t\t
                  \n\t\t\t
                  \n\t\t\t\t\t\t
                  \n\t\t\t\t
                  \n\t\t\t\t\t

                  Kiedy NIE u\u017cywamy?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                  \n\t\t\t\t
                  \n\t\t\t\t\t\t\t\t\t
                    \n
                  • Chcemy uzyska\u0107 100% pokrycia
                    Testowanie wszystkich funkcji, \u0142\u0105cznie z getterami i setterami nie ma sensu. Je\u017celi tak podstawowe funkcje nie dzia\u0142aj\u0105, to oznacza to, \u017ce co\u015b si\u0119 dzieje z ca\u0142ym j\u0119zykiem programowania lub kompilatorem, a nie naszym kodem.<\/li>\n
                  • Prototypowanie
                    Jest to eksperyment, kt\u00f3ry ma nam pokaza\u0107, czy co\u015b dzia\u0142a, czy nie dzia\u0142a. Nie jest to kod maj\u0105cy by\u0107 zamieniony na prawdziwy system, wi\u0119c nie trzeba wtedy robi\u0107 TDD.<\/li>\n
                  • Game Dev
                    Pisanie test\u00f3w do tego jak wygl\u0105da dana posta\u0107 b\u0105d\u017a jak si\u0119 rusza nie ma sensu.<\/li>\n
                  • UI\/Wygl\u0105d
                    Nie powinni\u015bmy testowa\u0107 w kt\u00f3rym miejscu jest Label, a kt\u00f3rym Button. Owszem, nale\u017cy przetestowa\u0107, czy ten przycisk dzia\u0142a po klikni\u0119ciu, ale nie jego wygl\u0105d.<\/li>\n
                  • Data Science<\/li>\n<\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                    \n\t\t\t\t\t\t
                    \n\t\t\t\t\t
                    \n\t\t\t
                    \n\t\t\t\t\t\t
                    \n\t\t\t\t
                    \n\t\t\t\t\t

                    Wady TDD<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                    \n\t\t\t\t
                    \n\t\t\t\t\t\t\t\t\t
                    • Spowalnia pisanie kodu produkcyjnego<\/li>
                    • Blokuje pisanie prostych funkcji (poniewa\u017c najpierw trzeba jeszcze napisa\u0107 do niej test)<\/li>
                    • Przy pisaniu nieczytelnych test\u00f3w ka\u017cdy b\u0142\u0105d mocno wyd\u0142u\u017ca prac\u0119<\/li>
                    • Niekt\u00f3re testy mog\u0105 zosta\u0107 tak napisane, \u017ce b\u0119d\u0105 zale\u017cne od innych i b\u0142\u0105d pierwszych b\u0119dzie powodowa\u0142 b\u0142\u0105d kolejnych<\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                      \n\t\t\t\t\t\t
                      \n\t\t\t\t\t
                      \n\t\t\t
                      \n\t\t\t\t\t\t
                      \n\t\t\t\t
                      \n\t\t\t\t\t

                      Przyk\u0142ad<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                      \n\t\t\t\t
                      \n\t\t\t\t\t\t\t\t\t

                      Chcemy stworzy\u0107 metod\u0119, kt\u00f3ra sprawdza czy podana liczba jest pierwsza. Je\u017celi tak, zwraca warto\u015b\u0107 'true’, je\u017celi
                      nie- 'false’. Korzysta\u0107 b\u0119d\u0119 z jUnit5 i dzieli\u0107 linie kody wg zasad Behavior-Driven Development.<\/p>

                      W pierwszej kolejno\u015bci tworzymy test do tej metody:<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                      \n\t\t\t\t
                      \n\t\t\t\t\t
                      @Test\nvoid givenPrimeNumberShouldReturnTrue(){\n    \/\/given\n    Example example = new Example();\n    int number = 13;\n\n    \/\/then\n    assertTrue(example.isNumberPrime(number));\n} <\/code><\/pre>