Dołącz do Governautów, zarejestruj się
Załóż konto
Reklama

Drogi użytkowniku!
Wygląda na to, że używasz rozszerzenia blokującego reklamy.
W Governice nie stosujemy nachalnych reklam. Możesz bezpiecznie odblokować je na naszej stronie ;-)
Zarządzanie jakością IT, systemy informatyczne, oprogramowanie biznesowe i inżynieria oprogramowania – to przykładowe zagadnienia, którym poświęcony jest dział Zarządzanie informatyką. Z haseł i artykułów można dowiedzieć się także o nadzorze IT, interakcji człowieka z komputerem czy wsparciu użytkowników IT.
Test-Driven Development Przekierowano ze strony: TDD
Test-driven development (TDD) - technika programowania należąca do grupy metodyk zwinnych inżynierii oprogramowania. Pierwotnie była częścią programowania ekstremalnego, lecz obecnie stanowi samodzielną technikę. Jest procesem programowania, który polega na powtarzaniu bardzo krótkich cyklów rozwoju i tworzenia.
Rozwój standardu
Zastosowanie
Rozwijanie
Generalną zasadą TDD jest pisanie testów jednostkowych przed tworzeniem właściwego kodu. Jak pokazuje praktyka, nie ma większego sensu tworzenie testów jednostkowych do istniejącego kodu (jakość takich testów zazwyczaj jest bardzo niska), zatem pozostaje w istniejących projektach tworzenie testów jednostkowych do nowej funkcjonalności oraz korzystanie z pełni dobrodziejstw Test-Driven Development w nowych projektach.Opis
- Stworzenie testu jednostkowego
- Implementacja funkcjonalności
- Refaktoryzacja
Stworzenie testu jednostkowego
Pierwszy krok to przygotowanie takiego testu, który będzie testował funkcjonalność, którą będzie można dopiero tworzyć. To daje czas na przemyślenie interfejsu tej funkcjonalności oraz pozwala skupić się nad tym, czego tak naprawdę oczekuje się od implementowanej później funkcjonalności. Czas poświęcony na tworzenie testu skutecznie zmusza programistę do sprecyzowania problemu, z jakim ma się zmierzyć.Implementacja funkcjonalności
Drugi krok to implementacja funkcjonalności. Dopiero mając test, przechodzi się do implementacji funkcjonalności. Co ważne, wprowadzane zmiany nie mogą naruszać innych testów, dzięki czemu mamy pewność, że nowo tworzona funkcjonalność nie zaburza tej już istniejącej.Refaktoryzacja
Trzeci krok to refaktoryzacja, czyli uporządkowanie kodu, doprowadzenie go do stanu zgodnego ze standardami dobrego kodowania. Zmiany wprowadzane podczas refaktoryzacji nie mogę powodować błędów w wykonaniu zarówno testu jednostkowego z pierwszego kroku, jak i tych, które powstały wcześniej. Jest to pierwszy etap, na którym testy jednostkowe zaczynają pokazywać swoją potęgę – jeżeli jakakolwiek zmiana wprowadzona w kodzie powoduje, że jeden lub więcej testów przestaje działać, to wprowadzona zmiana najprawdopodobniej generuje błąd.Wady i zalety
Metodologia TDD posiada dwie główne wady:
- TDD wymaga dodatkowego czasu na stworzenie testów jednostkowych - może być to bardzo zniechęcające dla kierownictwa, szczególnie w początkowym okresie korzystania z TDD, kiedy deweloper potrzebuje czasem nawet do 30% więcej czasu na wykonanie tych samych zadań. Z czasem jednak, po nabraniu płynności w pisaniu testów, ten dodatkowy czas zmniejsza się, dzięki czemu koszt stosowania tej metodologii maleje.
- TDD wymaga czasu w na utrzymanie testów - wynika to z faktu, że aby testy były użyteczne, muszą być odpowiednio zarządzane i uaktualniane wraz ze zmianami logiki aplikacji. Dopóki dodaje się nową funkcjonalność, problem ten praktycznie nie istnieje, jednak przy wprowadzaniu zmian w istniejącej funkcjonalności należy pamiętać, że potrzebny jest czas na odpowiednie zmodyfikowanie istniejących testów jednostkowych.
Zalety:
- Szybkie wychwytywanie błędów - już w momencie tworzenia oprogramowania wiele błędów można wychwycić za pomocą tej metodologii. Nie jest to bez znaczenia, ponieważ każdy błąd z czasem „nabiera wartości” a im później błąd zostanie wykryty, tym więcej osób angażuje i tym więcej kosztuje zarówno w aspekcie czasu, jak i pieniędzy. Wobec tego ważnym jest, aby wszystkie błędy były wychwytywane możliwie najszybciej i jak najbliżej programisty. Błędy wykryte przez autora kodu i poprawiane na bieżąco kosztują niewiele, ponieważ angażują tylko jedną osobę. Błędy wykryte przez zespół angażuje już czas zarówno programisty, jak i testera (lub testerów), co znacząco podwyższa koszty.
- Przemyślany kod - ponieważ w pierwszym kroku tworzony jest kod, który będzie wykorzystywał tworzoną funkcjonalność (test), to zazwyczaj naturalnie ten kod jest bardzo prosty i elegancki. Tak stworzony test wymaga, aby tworzona klasa była schludna i prosta do wykorzystania. Jest to efekt, który bardzo łatwo się osiąga – bez dodatkowego nakładu pracy – a przy okazji bardzo cenny szczególnie dla początkujących programistów.
- Możliwość przetestowania funkcjonalności bez uruchamiania całego oprogramowania – tworzony kod można uruchamiać częściowo, bez uruchamiania całej aplikacji. Nie ma to szczególnego znaczenia w małych projektach, ale już przy średnich i dużych czas jest niezwykle istotny. Za pomocą kilku kliknięć myszy, nie wychodząc z ulubionego środowiska programistycznego, można uruchomić części aplikacji i otrzymać miarodajne wyniki i to bez żmudnego uruchamiania kodu, bez męczącego przeszukiwania aplikacji i bez tracenia czasu na ponowne koncentrowanie się na istotnym problemie. Test jednostkowy pozwala w ciągu kilku sekund odpowiedzieć na pytanie, czy dany kawałek kodu będzie działał tak, jak chciał tego programista.
Zobacz też
Bibliografia
- Test-driven development, Wikipedia pl
- Test-driven development, Wikipedia en
ostatnia modyfikacja 20 sierpnia 2016 r.