Test driven development: Różnice pomiędzy wersjami
Z Encyklopedia Zarządzania
m (Dodanie TL;DR) |
mNie podano opisu zmian |
||
| (Nie pokazano 13 wersji utworzonych przez 2 użytkowników) | |||
| Linia 1: | Linia 1: | ||
'''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]. | |||
'''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]. | |||
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 23: | Linia 7: | ||
==Geneza TDD== | ==Geneza TDD== | ||
Pomysł opracowywania testów przed rozpoczęciem programowania nie jest unikalny dla społeczności [[Agile Project Management|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ę. | Pomysł opracowywania testów przed rozpoczęciem programowania nie jest unikalny dla społeczności [[Agile Project Management|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) | * '''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" | ||
| Linia 33: | Linia 14: | ||
* '''1998''': artykuł na temat Extreme Programming wspomina, że "zwykle najpierw piszemy test" | * '''1998''': artykuł na temat Extreme Programming wspomina, że "zwykle najpierw piszemy test" | ||
* '''1998 do 2002''': "Test First" jest opracowany w "Test Driven" | * '''1998 do 2002''': "Test First" jest opracowany w "Test Driven" | ||
* '''2000''': automatyzowane testy należą do nowatorskich technik opracowanych w tym okresie | * '''2000''': automatyzowane testy należą do nowatorskich technik opracowanych w tym okresie | ||
* '''2003''': publikacja "Test Driven Development: By Example" autorstwa Kenta Becka [Glossary Agile Alliance] | * '''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]. | 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]. | ||
<google>n</google> | |||
==Główne atrybuty i ogólny proces TDD== | ==Główne atrybuty i ogólny proces TDD== | ||
| Linia 45: | Linia 28: | ||
'''Najmniejszy cykl TDD zwykle zawiera trzy kroki:''' | '''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]. | * ''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 | 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== | ==Korzyści stosowania TDD== | ||
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 | ==Dopuszczane blędy przy stosowaniu TDD== | ||
''[[Błąd|Blędy]] dopuszczane ze strony poszczególnych osób:'' | ''[[Błąd|Blędy]] dopuszczane ze strony poszczególnych osób:'' | ||
* 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 | ||
* pisanie testów dla trywialnego kodu, na przykład accessorów | * pisanie testów dla trywialnego kodu, na przykład accessorów | ||
''[[Błąd|Blędy]] dopuszczane ze strony zespołu:'' | ''[[Błąd|Blędy]] dopuszczane ze strony zespołu:'' | ||
* częściowe przyjęcie - tylko kilku programistów w zespole korzysta z TDD | * 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 | * 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 | * 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. | |||
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. | ||
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. | Dodatkowo, te ramy testowe mają tendencję do zapewniania ramy wykonawczej dla automatyzacji wszystkich przypadków testowych systemu. | ||
| Linia 90: | Linia 68: | ||
* cppUnit | * cppUnit | ||
* UnitTest++ | * UnitTest++ | ||
* Unity | * Unity © [Pathfinder Solutions 2012, s. 8] | ||
{{infobox5|list1={{i5link|a=[[Epic]]}} — {{i5link|a=[[Backlog produktu]]}} — {{i5link|a=[[Inżynieria oprogramowania]]}} — {{i5link|a=[[Feature-Driven Development]]}} — {{i5link|a=[[Metodyka Extreme Programming]]}} — {{i5link|a=[[Lean Software Development]]}} — {{i5link|a=[[Programowanie strukturalne]]}} — {{i5link|a=[[CAD]]}} — {{i5link|a=[[Testowanie w projekcie]]}} }} | |||
==Bibliografia== | ==Bibliografia== | ||
* Beck K. | <noautolinks> | ||
* 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 | |||
* Hammond S., Umphress D. | * Harvey K. (2015), ''Test-Driven Development with Django'', Packt Publishing, UK | ||
* Harvey K. | * Mäkinen S., Münch J. (2014), ''Effects of Test-Driven Development: A Comparative Analysis of Empirical Studies'', University of Helsinki, Springer | ||
* Mäkinen S., Münch J. | * Pathfinder Solutions (2012), ''Effective TDD for Complex Embedded Systems'' | ||
* Pathfinder Solutions | * Percival H. (2017), ''Test-Driven Development with Python'', O’Reilly Media, USA | ||
* Percival H. | * Strona internetowa: ''[https://www.agilealliance.org/glossary/tdd/ Agile Alliance - TDD]'' | ||
* Duka D., Hribar L. (2010), ''Test Driven Development Method in Software Development Process'', Ericsson Nikola Tesla, Croatia | |||
</noautolinks> | |||
{{a|Serhiienko Maiia}} | {{a|Serhiienko Maiia}} | ||
[[Kategoria:Metodyki zarządzania projektami]] | |||
{{#metamaster:description|Test-driven development - podejście do rozwoju oprogramowania, w którym tworzy się najpierw testy akceptacyjne, a potem kod je spełnia. Wymaga dyscypliny, ale daje lepszą jakość i łatwiejsze utrzymanie kodu.}} | |||
Aktualna wersja na dzień 09:54, 18 sty 2024
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:
- 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 © [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
