Test driven development: Różnice pomiędzy wersjami
m (Infobox update) |
(LinkTitles.) |
||
| Linia 15: | Linia 15: | ||
'''Test-driven development (TDD)''' jest podejściem do rozwoju oprogramowania w sektorze IT, w którym najperw pisany jest ''[[Testy akceptacyjne odbiorcze|test]]'', następnie ''kod produkcyjny'' przechodzący ten test. Cykl zamyka ''refaktoring''. | '''Test-driven development (TDD)''' jest podejściem do rozwoju oprogramowania w sektorze IT, w którym najperw pisany jest ''[[Testy akceptacyjne odbiorcze|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]. | '''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 [[Testy akceptacyjne odbiorcze|testów]] spełniającego zadane wymagania. | Tradycyjny TDD skupia się na rozpoczęciu prac od najmniejszego zakresu [[Testy akceptacyjne odbiorcze|testów]] spełniającego zadane wymagania. | ||
| Linia 25: | Linia 25: | ||
* '''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) | * '''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" | * '''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 | * '''1991''': niezależne stworzenie ram testowych w Taligent z uderzającymi podobieństwami do SUnit | ||
* '''1994''': Kent Beck pisze szkielet testowy SUnit dla Smalltalk | * '''1994''': Kent Beck pisze szkielet testowy SUnit dla Smalltalk | ||
| Linia 39: | Linia 39: | ||
* ''Unit tests (testy jednostkowe)'' - testują aplikację od środka, z punktu widzenia programisty. | * ''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ą. | * ''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". | Ten [[proces]] jest podstawą całej praktyki TDD, który jest nazywany "Red/Green/Refactor". | ||
'''Najmniejszy cykl TDD zwykle zawiera trzy kroki:''' | '''Najmniejszy cykl TDD zwykle zawiera trzy kroki:''' | ||
| Linia 53: | Linia 53: | ||
Najwyżej na liście korzyści dla praktykujących TDD są: | 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. | * ''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. | * ''[[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. | * ''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]. | * 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. | 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. | 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] | 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 [[Błąd|blędy]] przy stosowaniu TDD== | ==Dopuszczane [[Błąd|blędy]] przy stosowaniu TDD== | ||
| Linia 66: | Linia 66: | ||
* częste zapomnienie o przeprowadzaniu testów | * częste zapomnienie o przeprowadzaniu testów | ||
* pisanie zbyt wielu testów naraz | * pisanie [[zbyt]] wielu testów naraz | ||
* pisanie testów, które są zbyt duże | * pisanie testów, które są zbyt duże | ||
* pisanie zbyt trywialnych testów, na przykład pomijanie asercji | * pisanie zbyt trywialnych testów, na przykład pomijanie asercji | ||
| Linia 97: | Linia 97: | ||
* Mäkinen S., Münch J., (2014) ''[http://www.sserg.org/publications/uploads/04b700e040d0cac8681ba3d039be87a56020dd41.pdf Effects of Test-Driven Development: A Comparative Analysis of Empirical Studies ]'', University of Helsinki, Springer | * Mäkinen S., Münch J., (2014) ''[http://www.sserg.org/publications/uploads/04b700e040d0cac8681ba3d039be87a56020dd41.pdf Effects of Test-Driven Development: A Comparative Analysis of Empirical Studies ]'', University of Helsinki, Springer | ||
* Pathfinder Solutions, (2012) ''[http://www.pathfindersolns.com/wp-content/uploads/2012/05/Effective-TDD-Executive-Summary.pdf Effective TDD for Complex Embedded Systems]'', Version 1.09 | * Pathfinder Solutions, (2012) ''[http://www.pathfindersolns.com/wp-content/uploads/2012/05/Effective-TDD-Executive-Summary.pdf Effective TDD for Complex Embedded Systems]'', Version 1.09 | ||
* Percival H., (2017) ''Test-Driven Development with Python'', O’Reilly Media, USA | * Percival H., (2017) ''Test-Driven Development with [[Python]]'', O’Reilly Media, USA | ||
Wersja z 04:48, 22 maj 2020
| Test driven development |
|---|
| Polecane artykuły |
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.
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:
- Napisanie testu jednostkowego, który się nie powiedzie (Red).
- Napisanie najprostszego możliwego kodu, aby go przekazać (Green).
- 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 (C) [Pathfinder Solutions 2012, s. 8]
Bibliografia
- Beck K., (2003) Test-driven Development: By Example , Pearson Education, Inc, USA
- Duka D., Hribar L., (2010) Test Driven Development Method in Software Development Process, Ericsson Nikola Tesla, Croatia
- Glossary Agile Alliance
- 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, Version 1.09
- Percival H., (2017) Test-Driven Development with Python, O’Reilly Media, USA
Autor: Serhiienko Maiia
