Nigdy nie testowałem, a teraz mam prikaz. Jak zacząć?

0

Mam do wykonania robotę... i prikaz, że jest bardzo ważne, by były testy. (robota jest na przedmiot na studia ale zleceniodawca i beneficjent to osoba z zewnątrz).

Mój problem polega na tym, że zwykle do pomysłu testowania podchodziłem alergicznie, bo mi się nie chciało i (apriorycznie) wydawało mi się to wielce nudne, czasochłonne, żmudne, bezsensowne. W konsekwencji w swoim życiu testy napisałem tylko raz: jak był projekt czysto studencko-ćwiczebny w którym warunkiem zaliczenia było przestestowanie jednego jego fragmentu. A i wtedy "wykręciłem się sianem", tj napisałem testy tylko takie, by ćwiczeniowiec odp... się ode mnie i nie oblał mi zadania wył za brak testów.

Cóż, pewnie tym podejściem sam sobie zaszkodziłem... ale pytanie pozostaje co powinienem zrobić teraz?

Oto dylemat: Z jednej strony jak przeglądałem to forum w tym temacie to znalazłem taką wypowiedź:

jarekr000000 napisał(a):

Natomiast pisanie testów po implementacji jest bzdurą. Czasami jak mi ktoś w zespole powie, że wszystko działa i tylko musi teraz napisać testy -- to mówię, żeby tego nie robił. Te testy "po", już niczego nie wnoszą. Tak się zdarza, jak jest ktoś nowy, albo pracuje nad nową technologią i nie ogarnia jak w niej testować.

Ale z drugiej strony (tu już na szybko nie znajdę cytatów) czytałem że TDD to metoda która choć, jeśli wierzyć jej proponentom, daje najlepsze rezultaty spośród obecnie dostępnych, to jednak wymaga ona wpierw całkiem solidnego i czasochłonnego treningu, zanim będzie można zacząć ją stosować w projektach innych niż tylko tych przeznaczonych jedynie i wyłącznie nauce TDD.

Wychodzi więc na to, że nie mam pisać testów ani po implementacji (bo bzdura), ani przed implementacją (bo nie ten poziom wtajemniczenia), ale jednak testy napisać mam obowiązek...?

Zastanawiam się, jak z tego wybrnąć.

3

Nawet jak napiszesz testy po implementacji to te będą sprawdzać czy po wprowadzeniu zmian niczego nie zepsułeś. Jednak pisanie testów względnie późno oznacza, że późno zaczną wyłapywać ewentualne błędy, a także że kod będzie potencjalnie słabo testowalny co poskutkuje zrobieniem kiepskich testów (bo nie będzie się opłacać przerabiać całego kodu pod solidne testy).

Może spróbuj pisać testy od razu jak pojawi ci się w głowie pomysł jak testować daną funkcjonalność albo jak pokrycie testami logiki spadnie poniżej akceptowalnego poziomu.

1 użytkowników online, w tym zalogowanych: 0, gości: 1