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

Odpowiedz Nowy wątek
2018-11-03 18:23
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ąć.

Pozostało 580 znaków

2018-11-04 23:53
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.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
Prawda. Jakiś czas temu sam wpadłem w taką pułapkę. Wchodziłem w całkiem nową technologię i najpierw coś popisałem, a w trakcie tworzenia projektu zacząłem robić testy. I fajnie. Ale w pewnym momencie się okazało, że nie wszystko da się przetestować z tego, co powinno :) - Juhas 2018-11-08 10:45

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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