Dlaczego Test Driven Development (TDD) to najlepszy sposób na niezawodne kodowanie.

Najpierw napisz testy jednostkowe, a następnie napisz kod.

Kredyty obrazkowe: Pexels.com

Kilka lat temu, kiedy po raz pierwszy usłyszałem o „Test Driven Development”, byłem sceptyczny.

Sam pomysł „najpierw napisz testy jednostkowe, a potem napisz kod” był dla mnie bełkotem.

Dlaczego nie miałby być? Najpierw napisz testy jednostkowe? Kto by zrobił takie głupie rzeczy?

Ale do tej pory byłem profesjonalnym programistą przez 10 lat i widziałem, jak sprawy pojawiają się i znikają w branży. Wiedziałem, że lepiej nie odrzucać czegokolwiek z ręki, szczególnie, gdy programiści byli tak ostrożni.

Skonsultowałem się więc z przyjacielem, który pokazał mi podstawowy przykład.

Ten podstawowy przykład ma klasę LCL_SUM z metodą SUM. Obowiązkiem tej metody jest DODAWANIE liczb. Pobiera liczbę jako parametr importujący, a następnie dodaje ją do siebie, aby uzyskać wynik. Nazwijmy tę metodę jako metodę produkcji.

Kod klasy wyglądał następująco:

KLASA lcl_sum DEFINICJA.
SEKCJA PUBLICZNA.
METODY: IMPORTOWANIE PODSUMOWANIA iv_1 TYP i
WARTOŚĆ ZWRACANA (suma rv) TYP i.
ENDCLASS. „Lcl_sum DEFINICJA
*
ROZPOCZĘCIE WYBORU.
* Nic tu jeszcze nie ma
*
*
KLASA lcl_sum REALIZACJA.
SUMA METODY.
rv_sum = iv_1 * iv_1. „Umyślny błąd (mnożę zamiast dodawać)
WIECZÓR. "suma
ENDCLASS. „Lcl_sum REALIZACJA.

Konfiguracja klasy testowej

Teraz stwórz klasę, która działa jak klasa testowa. W SAP należy zdefiniować słowo kluczowe FOR TESTOWANIE podczas definiowania klasy. Ten dodatek oddziela tę klasę od kodu produkcyjnego.

KLASA lcl_test DEFINICJA TESTOWANIA
SEKCJA PUBLICZNA.
METODY: m_sum DO TESTOWANIA.
ENDCLASS. „Lcl_test DEFINITION
*
KLASA lcl_test WDROŻENIE.
METODA m_sum.
WIECZÓR. „M_sum
ENDCLASS. „Lcl_test WDROŻENIE

Implementacja metody testowej

W tej metodzie testowej musisz - przetestować kod produkcyjny. Tak więc, aby móc przetestować metodę SUM LCL_SUM, musisz utworzyć instancję odwołania do obiektu LCL_SUM, wywołaj metodę SUM wysyłającą wartość fikcyjną.

Na podstawie wartości Dummy metoda wyśle ​​Ci wynik - rzeczywisty wynik z metody. W oparciu o wartość manekina wiesz, jaka byłaby oczekiwana wartość. Na przykład. Jeśli przekażesz numer 3 metodzie SUM, da ci wynik 6, ponieważ dodaje się do 3.

Po otrzymaniu rzeczywistego wyniku z testowanego kodu produkcyjnego lub metody należy porównać wyniki. Jeśli rzeczywista vs.

KLASA lcl_test WDROŻENIE.
METODA m_sum.
DANE: o_cut TYPE REF TO lcl_sum.
DANE: lv_result TYPE i.
*
UTWÓRZ OBIEKT o_cut.
lv_result = o_cut-> sum (3).
*
cl_aunit_assert => assert_equals (
Termin ważności = 6
act = lv_result
msg = „coś złego w wyjściu”
).
WIECZÓR. „M_sum
ENDCLASS. „Lcl_test WDROŻENIE

Wyniki testu jednostkowego

To mówi mi, że coś jest nie tak z implementacją metody produkcji.

Tak, jeśli przyjrzysz się bliżej implementacji SUM metody, mam literówkę - zamiast używania Sumacji użyłem Mnożenia. Więc poprawiłbym to i ponownie uruchomiłem test, aby wykonać go pomyślnie.

Byłem uzależniony od TDD. Flabbergasted byłoby właściwym słowem.

Zadziwiające było bardzo skrócenie czasu cyklu opracowywania i testowania.

Byłem przyzwyczajony do pisania kodu przez większą część godziny, zanim spróbowałem go skompilować lub uruchomić. Ale tutaj kod był wykonywany i testowany co około 2 minuty.

W skrócie, TDD jest realizowany poprzez krótkie cykle programowania, które są zgodne z zasadą „najpierw napisz testy jednostkowe, następnie napisz kod, następnie refaktoryzuj, a następnie powtórz”. Testy jednostkowe to automatyczne testy, które sprawdzają, czy funkcje działają zgodnie z oczekiwaniami. Twój pierwszy test jednostkowy powinien zakończyć się niepowodzeniem, ponieważ jest napisany, zanim jeszcze będziesz mieć bazę kodu.

Dodajesz trochę do kodu przypadku testowego. Dodajesz trochę do kodu produkcyjnego. Dwa strumienie kodu rosną jednocześnie w uzupełniające się komponenty. Testy pasują do kodu produkcyjnego, tak jak przeciwciało pasuje do antygenu.

Ten środek uniemożliwia programistom pisanie niepotrzebnego kodu, który nie jest zgodny z danym testem.

I to całe zintegrowane podejście oferuje wiele korzyści dla programisty.

Naprawiasz zły kod bez zerwania czegokolwiek.

Ilekroć widzisz zły kod, przewracasz oczami, modlisz się do Boga i wypowiadasz jedno z dwóch stwierdzeń.

· "To jest bałagan. Chyba muszę to jakoś naprawić ”.

· „Nie dotykam tego”.

W obu przypadkach występuje element strachu. W rzeczywistości niepewność.

Co jeśli mój kod zepsuje istniejącą funkcjonalność?

TDD pomaga precyzyjnie pokonać tę niepewność.

Należy zauważyć, że w środowisku TDD programiści koncentrują się na przeprowadzaniu testów, aby zapobiegać błędom, zamiast je usuwać po napisaniu kodu. Jest to jedna z najpotężniejszych zalet TDD. Kiedy masz pakiet testów, którym ufasz, tracisz wszelki strach przed wprowadzaniem zmian. Gdy zobaczysz zły kod, po prostu go wyczyść na miejscu.

A im bardziej przejrzysty kod, tym mniej wysiłku Twój zespół musi włożyć w dodanie nowych funkcji lub modyfikację istniejącej bazy kodu.

TDD wymusza dokumentację.

Dick Brandon uderzył go w gwóźdź, gdy zauważył.

„Dokumentacja jest jak seks; kiedy jest dobry, jest bardzo, bardzo dobry, a gdy jest zły, jest lepszy niż nic ”.

Dokumentacja jest olejem rycynowym programowania. Menedżerowie uważają, że jest to dobre dla programistów, a programiści go nienawidzą!

jednym z powszechnych powodów występowania pełzania zakresu jest brak dokumentacji z jasno określonymi wymaganiami. Problem ten można złagodzić dzięki rozwojowi opartemu na testach.

W środowisku TDD programiści piszą testy jednostkowe w celu przetestowania poszczególnych segmentów kodu. Testy jednostkowe służą jako specyfikacje opisujące dokładne funkcje, które należy wdrożyć. Dlatego dokładnie określone testy uniemożliwiają programistom pisanie zbędnego kodu.

A te testy jednostkowe są dokumentami. Opisują projekt najniższego poziomu systemu. Są jednoznaczne, dokładne, napisane w języku zrozumiałym dla publiczności i są tak formalne, że wykonują. Są najlepszym rodzajem dokumentacji niskiego poziomu, która może istnieć.

TDD pomaga w lepszym projektowaniu

Podstawowym warunkiem TDD jest napisanie przypadków testowych przed napisaniem kodu.

Problem z testowaniem kodu polega na tym, że musisz go wyodrębnić. Często trudno jest przetestować funkcję, jeśli wywołuje ona inne funkcje. Aby napisać ten test, musisz znaleźć sposób na oddzielenie funkcji od wszystkich innych. Innymi słowy, potrzeba przetestowania najpierw zmusza do myślenia o dobrym projekcie.

To tworzy lepszy, oddzielony projekt, w którym masz lepszą kontrolę nad rzeczami w miarę rozwoju kodu.

Pisanie przypadków testowych z góry może początkowo pochłaniać czas, ale przynosi to wiele korzyści. Deweloperzy przyznają, że wcześniej pisali wiersze kodu, zdawali sobie sprawę, że ich rozwiązania były nieistotne, a następnie zaczynali od nowa kodować.

W przeciwieństwie do przestarzałych praktyk kodowania, TDD pozwala programistom wrócić do deski kreślarskiej i skoncentrować się na zaprojektowaniu lekkiej, elastycznej architektury z góry.

Sam fakt pisania z góry przypadków testowych zapobiega wszelkim błędom, które mogą się później pojawić, oszczędzając czas, wysiłek i zgagę.

Wreszcie TDD przestrzega najlepszych praktyk kodowania.

TDD promuje dobre zasady kodowania, w tym DRY, KISS, YAGNI i SOLID.

Zasada DRY (Don't Repeat Yourself) mówi programistom, aby unikali powtarzania tego samego kodu w różnych częściach tego samego systemu, dlatego też jest czasami nazywana zasadą DIE (Duplikacja jest zła). DRY zaleca programistom wykorzystanie klas i funkcji do enkapsulacji funkcjonalności systemu i utrzymania spójnej bazy kodu.

Zasada KISS (Keep it Simple, Stupid!) Radzi programistom, aby nie wymyślali na nowo koła, ale budowali proste i przejrzyste architektury. Istotą KISS jest unikanie nadmiernie zaprojektowanych rozwiązań.

Zasada YAGNI (Nie potrzebujesz go) walczy ze złoceniem. Pozłacanie może wydawać się nieszkodliwe, szczególnie jeśli programista chce ulepszyć istniejącą funkcjonalność, aby zadowolić klienta. Jednak powoduje to dodatkowy czas programowania, co może spowodować opóźnienie projektu lub niezadowolenie klienta. YAGNI wyjaśnia: programista powinien wdrażać tylko przydzielone zadania i unikać dodawania nadmiernej funkcjonalności.

SOLID składa się z pięciu zasad w jednym: pojedyncza odpowiedzialność, otwarte-zamknięte, podstawienie Liskowa, segregacja interfejsu i inwersja zależności. Krótko mówiąc, SOLID stwierdza, że ​​przestrzeganie tych zasad ułatwia utrzymanie i testowanie aplikacji.

Krótko mówiąc, TDD pomaga w tworzeniu eleganckiego i prostego kodu, który jest łatwy w utrzymaniu.

Jak trafnie powiedział Robert Martin.

„Czysty kod zawsze wygląda tak, jakby został napisany przez kogoś, kogo to obchodzi”.

Bibliografia

Programowanie ekstremalne: Kent Beck.

Zwinne tworzenie oprogramowania: Robert Martin

Refaktoryzacja: Martin Fowler

O autorze-:

Ravi Rajan jest globalnym menedżerem programów IT z siedzibą w Bombaju w Indiach. Jest także zapalonym blogerem, pisarzem poezji Haiku, miłośnikiem archeologii i maniakiem historii. Połącz się z Ravi na LinkedIn, Medium i Twitterze.

Ta historia została opublikowana w The Startup, największej publikacji na temat przedsiębiorczości na średnim poziomie, a następnie +438,678 osób.

Zapisz się, aby otrzymywać nasze najlepsze historie tutaj.