Test driven development

Test-driven development (TDD) jest podejściem do rozwoju oprogramowania w sektorze IT, w którym najperw pisany jest test, następnie kod produkcyjny przechodzący ten test. Cykl zamyka refaktoring. TDD jest dyscypliną, co oznacza, że nie jest czymś, co przychodzi naturalnie; ponieważ korzyści nie są natychmiastowe, ale pojawiają się dopiero w dłuższej perspektywie. Koncept TDD nie mniej jednak zmusza do wykonania dużej ilości pracy w momencie rozpoczęcia pracy [Beck Kent 2003, s. 11]. Tradycyjny TDD skupia się na rozpoczęciu prac od najmniejszego zakresu testów spełniającego zadane wymagania.

TL;DR

Test-driven development (TDD) to podejście do rozwoju oprogramowania, w którym najpierw pisane są testy akceptacyjne, a następnie kod produkcyjny. TDD wymaga dużej ilości pracy na początku, ale ma wiele korzyści w dłuższej perspektywie. TDD skupia się na tworzeniu testów jednostkowych i refaktoryzacji. Korzyści stosowania TDD to szybkie rezultaty, elastyczność, automatyczny katalog testów regresji i dobry kod. TDD może zmniejszyć liczbę defektów i ułatwić utrzymanie kodu. Wadami TDD są błędy, takie jak zapominanie o testach, pisanie zbyt wielu lub zbyt trywialnych testów. Do praktykowania TDD używa się frameworków xUnit, takich jak Junit czy cppUnit.

Geneza TDD

Pomysł opracowywania testów przed rozpoczęciem programowania nie jest unikalny dla społeczności Agile. Podejście TDD różni się od innych metod, ponieważ łączy ten pomysł z pisaniem testów przez samego programistę. Ta koncepcja odnawia powszechny szacunek do testów tworzonych przez programistę.

• 1976: publikacja "Software Reliability" autorstwa Glenforda Myersa, który określa jako "aksjomat", że "programista nie powinien nigdy testować swojego własnego kodu" (Dark Age of Developer Testing)
• 1990: dyscyplina testowa zdominowana przez techniki "czarnej skrzynki", w szczególności w postaci narzędzi do testowania "przechwytywania i powtarzania"
• 1991: niezależne stworzenie ram testowych w Taligent z uderzającymi podobieństwami do SUnit
• 1994: Kent Beck pisze szkielet testowy SUnit dla Smalltalk
• 1998: artykuł na temat Extreme Programming wspomina, że "zwykle najpierw piszemy test"
• 1998 do 2002: "Test First" jest opracowany w "Test Driven"
• 2000: automatyzowane testy należą do nowatorskich technik opracowanych w tym okresie
• 2003: publikacja "Test Driven Development: By Example" autorstwa Kenta Becka [Glossary Agile Alliance]

W 2006 roku TDD staje dojrzałą techniką, która zaczęła zachęcać do dalszych innowacji, takich jak Acceptance Test Driven Development (ATDD) czy Behavior Driven Development (BDD) [Hammond S., Umphress D. 2015, s. 1-4].

Główne atrybuty i ogólny proces TDD

• Functional tests (testy funkcjonalne) - oni pozwalają zobaczyć funkcje aplikacji z punktu widzenia użytkownika. Oznacza to, że functional tests mogą być rodzajem specyfikacji dla aplikacji.
• Unit tests (testy jednostkowe) - testują aplikację od środka, z punktu widzenia programisty.
• The unit test/code cycle - jest ciągłym powtórzeniem tworzenia testów jednostkowych dopóki oni nie przejdą.

Ten proces jest podstawą całej praktyki TDD, który jest nazywany "Red/Green/Refactor".

Najmniejszy cykl TDD zwykle zawiera trzy kroki:

1. Napisanie testu jednostkowego, który się nie powiedzie (Red).
2. Napisanie najprostszego możliwego kodu, aby go przekazać (Green).
3. Refaktorowanie, aby uzyskać lepszy kod, który ma więcej sensu.

• Refaktoring - jest procesem przebudowy istniejącego kodu komputerowego bez zmiany jego zachowania zewnętrznego [Percival H. 2017, s. 38, 52].

Początkowy test jest poprzeczką ustawioną dla logiki, którą chcesz napisać. To jest dobrym sposobem, aby upewnić się, że testy pokrywają całość kodu i że zapewniają dokładnie to, co było zaplanowane [Harvey K. 2015]

Korzyści stosowania TDD

Najwyżej na liście korzyści dla praktykujących TDD są:

• Szybkie rezultaty: programiści mogą zobaczyć efekt decyzji projektowych w ciągu kilku minut.
• Elastyczność: zmiany są łatwe ze względu na niewielką odległość między zatwierdzeniami.
• Automatyczny katalog testów regresji: jeśli coś opracowane sześć miesięcy temu nagle złamie się pod dzisiejszym kodem, jest znane natychmiast.
• Dobry, czysty i działający kod [Duka D., Hribar L. 2010, s. 1-4].

Istotną zaletą TDD jest to, że umożliwia on wykonywanie małych kroków podczas pisania oprogramowania. Jest to popularna praktyka, ponieważ jest o wiele bardziej produktywna niż próba kodowania dużymi krokami. Wyniki dla dziesięciu różnych wewnętrznych i zewnętrznych atrybutów jakości wskazują, że rozwój sterowany testami może zmniejszyć liczbę wprowadzanych defektów i prowadzić do łatwiejszego utrzymania kodu. Części zaimplementowanego kodu mogą mieć nieco mniejszy rozmiar i złożoność. O ile utrzymanie kodu testowego może zająć mniej czasu, początkowy rozwój może trwać dłużej [Mäkinen S., Münch J. 2014, s. 1-2]

Dopuszczane blędy przy stosowaniu TDD

Blędy dopuszczane ze strony poszczególnych osób:

• częste zapomnienie o przeprowadzaniu testów
• pisanie zbyt wielu testów naraz
• pisanie testów, które są zbyt duże
• pisanie zbyt trywialnych testów, na przykład pomijanie asercji
• pisanie testów dla trywialnego kodu, na przykład accessorów

Blędy dopuszczane ze strony zespołu:

• częściowe przyjęcie - tylko kilku programistów w zespole korzysta z TDD
• słabe utrzymywanie zestawu testów - najczęściej prowadzące do zestawu testów z długim czasem działania
• opuszczony zestaw testów (rzadko lub nigdy nie uruchamiany) - czasami w wyniku złego utrzymywania, czasami w wyniku rotacji zespołu

Oprogramowanie wykorzystywane w TDD

Wielu praktyków TDD korzysta z frameworków xUnit, aby zapewnić test w stylu asercji, funkcje sprawdzania poprawności i raportowanie wyników. Te możliwości są kluczowe dla automatyzacji, przenoszenia ciężaru sprawdzania poprawności wykonania zadań z niezależnej postprocessingowej aktywności do tej, która jest uwzględniona w wykonaniu testu. Dodatkowo, te ramy testowe mają tendencję do zapewniania ramy wykonawczej dla automatyzacji wszystkich przypadków testowych systemu.

Przykładami xUnit Frameworks (narzędzia) są:

• Junit (3 & 4)
• cppUnit
• UnitTest++
• Unity © [Pathfinder Solutions 2012, s. 8]

Test driven development — artykuły polecane

Epic — Backlog produktu — Inżynieria oprogramowania — Feature-Driven Development — Metodyka Extreme Programming — Lean Software Development — Programowanie strukturalne — CAD — Testowanie w projekcie

Bibliografia

• Beck K. (2003), Development: By Example, Pearson Education, Inc, USA
• Hammond S., Umphress D. (2015), Test Driven Development: The State of the Practice, Auburn University
• Harvey K. (2015), Test-Driven Development with Django, Packt Publishing, UK
• Mäkinen S., Münch J. (2014), Effects of Test-Driven Development: A Comparative Analysis of Empirical Studies, University of Helsinki, Springer
• Pathfinder Solutions (2012), Effective TDD for Complex Embedded Systems
• Percival H. (2017), Test-Driven Development with Python, O’Reilly Media, USA
• Strona internetowa: Agile Alliance - TDD
• Duka D., Hribar L. (2010), Test Driven Development Method in Software Development Process, Ericsson Nikola Tesla, Croatia

Autor: Serhiienko Maiia