TDD - a rzeczywistość

Odpowiedz Nowy wątek
2016-12-03 21:59
0

Witam,

jestem w trakcie lektury "Mistrz czystego kodu" Robert C. Martin i napisał on:

//"1. Nie wolno napisać Ci nawet wiersza produktywnego kodu, jeżeli wcześniej nie napiszesz pasującego testu jednostkowego, który nie zostanie zaliczony.

  1. Nie wolno Ci napisać więcej testu jednostkowego, niż jest konieczne, żeby test nie został zaliczony. Nieudana kompilacja też powoduje, że test nie jest zaliczony.
  2. Nie wolno Ci napisać więcej produktywnego kodu, niż potrzeba, żeby aktualnie oblany test został zaliczony."
    //

Czy w praktyce jak piszecie aplikacje jakiekolwiek to stosujecie się to tych trzech zasad zawodowo i prywatnie??

nie stosuje się, bo uważam te zasady za głupie i oderwane od rzeczywistości - karolinaa 2016-12-24 19:05

Pozostało 580 znaków

2016-12-04 09:03
2

W pracy praktycznie 100% ( wyjątki to jakis naprawdę stary kod, kóry ma zaraz umrzeć , generalnie jak do zakończenia działania czegoś jest mniej niż 2 miesiące - to można czasem olać testy).

W projektach domowych róznie:

  • czasem stosuje złośliwe "TDD (kreatywność w punkcie 3)" - generalnie nie do końca polecam wobec kolegów, bo się odbija czkawką - ale jako ćwiczenie lubię,
  • w Scali staram się czasem przepisać testy na typy (średnio mi to wychodzi),
  • mam taki projekt, w którym naprawdę nie wiem co robię - wtedy też nie piszę testów,
  • czasem olewam testy zupełnie - stosuję zasadę 2 miesięcy - testy mniej więcej po takim czasie się zwracają - jak jest strzał na kilka dni i masz gwarancję, że kod po dwóch miesiącach nie bedzie dalej utrzymywany , i nie będzie działał - to można testy oszczędzić,

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ć.
Natomiast absolutnie wymagam testów po zraportowanym bugu - był bug w kodzie - to najpierw test odtwarzający bug - potem fix. (Bug driven tests).
Takie testy są najbardziej cennne. Czasami to jest całkiem niezłe wyzwanie, jak był np. bug na współbieżności, czasem się niestety też nie da - niektóre Heisenbugi.
( no i nadal w roku 2016 nie mam testów do CSS- czyli wywali się layout - jak to przetestować? JavaScript , typescript natomiast testuje się nawet lepiej niż Javę).


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 2x, ostatnio: jarekr000000, 2016-12-04 09:05
BDT to jest piękne podejście, jeszcze jak podepniesz do tego storage i automaty, które potrafią na podstawie historii bugów zrobić regresję. Ile to baboli my w ten sposób w systemach rozliczeniowych wyłapaliśmy przy migracjach. - Koziołek 2016-12-05 15:20
BDT - to rzeczywiście ma sens - karolinaa 2016-12-24 19:06

Pozostało 580 znaków

2016-12-04 09:11
0

Mam wrazenie, ze jak ktos autorytarnie nie zarzadzi, ze najpierw testy pozniej implementacja to ludzie nie naucza sie w ten sposob pisac. Pozniej jest to 'wola programisty' i nikt juz nie robi TDD bo zwolennicy poddaja sie jak pozniej maja wszystko refaktoryzowac.

Moze TDD nie jest idealne ale jest jednak lekarstwem na wiele rzeczy.

  • porzadkuje kod, lepszy design
  • single responsibility
  • jest wiecej testow ;)
  • wieksza czytelnosc, nazwy testow mowia co ma robic kod
  • im dalej w las tym bardziej czas na testy sie zwraca
edytowany 2x, ostatnio: rav3n, 2016-12-04 09:17

Pozostało 580 znaków

2016-12-04 09:45
0

to wychodzi na to że ucząc się nowego języka powinno się jednocześnie przerabiać testowanie w nim jak i samą składnie języka? od kiedy "programuje" czy to w pascalu kiedyś czy c/c++ czy innym języku nigdy nie spotkałem ani książki ani kursu, która by poruszała "oba" problemy jednocześnie. A wydaje mi się (mogę się mylić) że ucząc się języka nabieramy jakiś przyzwyczajeń itp i potem wprowadzając do tego testy musimy uczyć się na nowo "pisania". Pozbyć się jakiś przyzwyczajeń itd.

Pozostało 580 znaków

2016-12-04 09:46
0
rav3n napisał(a):

Mam wrazenie, ze jak ktos autorytarnie nie zarzadzi, ze najpierw testy pozniej implementacja to ludzie nie naucza sie w ten sposob pisac. Pozniej jest to 'wola programisty' i nikt juz nie robi TDD bo zwolennicy poddaja sie jak pozniej maja wszystko refaktoryzowac.

U mnie to nie działało. To co działa to wyszkolenie managementu w temacie "dług techniczny".
A na programistów... jedynie manipulacja :-(


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 1x, ostatnio: jarekr000000, 2016-12-04 09:54
dług techniczny, a nie technologiczny - Wibowit 2016-12-04 09:49
@Wibowit - dzieki, poprawiłem - jarekr000000 2016-12-04 09:54
Bez TDD moze moga pisac jacys bardzo doswiadczeni ludzie robiac POC. Ale na ogol kod bez TDD to masakra, robie zmiane, puszcam testy... Nic sie nie wywala. No i mam klasy, ktore sa serwisem, klientem i konwerterem na raz itp.. - rav3n 2016-12-04 10:00
Bez TDD moze moga pisac jacys bardzo doswiadczeni ludzie robiac POC bez przesady - karolinaa 2016-12-24 19:11

Pozostało 580 znaków

2016-12-04 09:55
0

Testy jednostkowe to must have. Im latwiej to robic w tecnologii X tym wiecej zyskuje w moich oczach.

Np. Golang.z dodatkowym libem jest bardzo spoko pod wzgledem testow i od razu mi zaplusowal w tym miejscu ;)

Latwo w internecie znajdziesz jak napisac prosty test w jezyku X.. Poczytaj o podejsciu TDD i zmus sie do pisania testow najpierw. Dobre IDE tez pomaga. Piszac test z metodami ktore nie istnieja i tworzysz puste lub rzucajace wyjatkami 'not implemented yet' generujac je z IDE. I zeby nie przeszedl Ci test bez implementacji czasem ;)

Pozostało 580 znaków

2016-12-04 10:09
0

to że testy są potrzebne wiem doskonale tzn rozumiem ich idee itp:) jakiś czas temu napisałem pewną aplikację na własny użytek (ma około 2000 linii kodu nie wiele no ale:) ) i właśnie się zastanawiam czy nie spróbować napisać tego jeszcze raz pisząc do tego testy. Tylko właśnie, uczyłem się cały czas np. javy ale bez JUnit np. bo przecież testy to nie tylko assertEquals przecież.

Przez chwilę przeszło mi przez myśl nawet napisanie testów do napisanej aplikacji... ale po chwili w mojej głowie pojawiało się inne rozwiązanie danego problemu i testy wymusiły by na mnie zmianę całego kodu.

Pozostało 580 znaków

2016-12-04 10:39
0

TDD jest jak Vim.

  1. zupełnie inne programowanie, żeby skutecznie pracować z TDD/Vimem trzeba się nauczyć nowych nawyków, zanim się nauczymy, będzie to niewygodne
  2. TDD jak i Vim ma dużo zalet i często przyśpieszają pracę (TDD = szybka pętla zwrotna, ochrona przed regresją, łatwość refaktoringu, Vim = potęga edycji, inteligentne komendy itp.)

Jednak zarówno jeśli chodzi o TDD jak i Vim, to nie osiągnąłem biegłości w żadnym z nich, więc korzystam z niemodalnego edytora (teraz z Atoma, ale robię już własny), a kod piszę w ten sposób, że najpierw jest hakerka(make it work), potem jest przemyślenie architektury(make it right), i dopiero na tym etapie piszę testy (inaczej musiałbym przepisywać testy kilka razy, bo między pierwszą a drugą fazą często zmieniam API danego modułu).

Chociaż muszę się zgodzić, że do fiksowania bugów TDD bardzo dobrze się sprawdza:

Natomiast absolutnie wymagam testów po zraportowanym bugu - był bug w kodzie - to najpierw test odtwarzający bug - potem fix. (Bug driven tests).
Takie testy są najbardziej cennne.

Szybki feedback "czy już działa" oraz zabezpieczenie przed pojawieniem się tego samego buga w przyszłości.

Także TDD sprawdza się u mnie jeśli wiem co robię (zwykle jednak jestem jak ten pies w stanie nieważkości z napisem "I have no idea what I'm doing")


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 2x, ostatnio: LukeJL, 2016-12-04 10:40

Pozostało 580 znaków

2016-12-04 19:02
Krwawy Szczur
0

Ja tego trochę sobie nie wyobrażam. Przecież pisząc kod... nie wiemy jak on będzie jeszcze wyglądał. Czasami zdarza się 10 razy zmieniać sygnaturę jakiejś metody czy przerabiać jedną klasę... to jak ja mam przewidzieć jak kod ma wyglądać przed jego napisaniem? Bo tego wymaga ode mnie TDD.

Pozostało 580 znaków

2016-12-04 19:09
0

Z TDD najpierw definiujesz zachowania, a potem je implementujesz.

Pozostało 580 znaków

2016-12-05 13:41
5

@jarekr000000

Te testy "po", już niczego nie wnoszą

Ktoś chyba nigdy nie słyszał o czymś takim jak regresja albo o błędach zwiazanych z refaktoryzacją kodu. Serio czasem czytając twoje posty zastanawiam sie czy pracowałeś dłużej przy jakimś (starszym) projekcie w fazie utrzymania. Staż by sugerował że musiało tak być, ale to co piszesz nijak...
Oczywiście jeśli ktoś chce ocenić jak przydatne są testy w chwili ich napisania zaraz po implementacji to wartość jest zerowa, o ile programista nie jest idiotą i nie napisał niedziałajacego kodu. Ale wartość testów wychodzi znacznie później, kiedy ktoś zaczyna coś refaktorować, zmieniać technologię, migrować itd.

Natomiast absolutnie wymagam testów po zraportowanym bugu

Ja mam nadzieje ze to jest standard wszędzie ;)

@rav3n

  • porzadkuje kod, lepszy design

Nigdy nie widziałem żeby podejscie test-first wygenerowało lepszy kod. Z mojego dświadczenia wynika ze generuje taki sam.

  • single responsibility

Nie widzę związku.

  • jest wiecej testow
    • wieksza czytelnosc, nazwy testow mowia co ma robic kod
    • im dalej w las tym bardziej czas na testy sie zwraca

To samo można powiedzieć o pisaniu testów w ogóle, niezależnie od tego czy to TDD czy cokolwiek innego. Ty chyba próbujesz przeciwstawić tutaj "pisanie testów" od "niepisania testów".

Przecież pisząc kod... nie wiemy jak on będzie jeszcze wyglądał

I nie musisz, bo chodzi tu raczej o testowanie "zachowania" czy też taki blackbox test. Więc interesuje cię co funkcja robi a nie jak wygląda od środka. Wiec generalnie tylko sama sygnatura ma jakieśtam znaczenie, żebyś mógł to sobie wywołać w teście. To zresztą jest też potem takie trochę programowanie top-down. Tzn najpierw definiujesz sobie same sygnatury a potem dopiero zaczynasz wypełniać je implementacją.


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
edytowany 1x, ostatnio: Shalom, 2016-12-05 13:42
Pokaż pozostałe 2 komentarze
patrząc po sobie to muszę stwierdzić, że to złudna nadzieja. Ja jeśli piszę cały moduł na TDD, to tworzę w rezultacie o wiele gorszy kod, przeinżynierowany (bo zamiast napisać coś od A do B to robię naokoło, myśląc bardziej o ładnym pisaniu testów niż o rzeczywistym problemie), więc raczej nie przepadam za TDD jako główną metodą developerki. - LukeJL 2016-12-05 16:32
Chociaż czasem pisząc TDD mogę coś przemyśleć, oczywiście, stosowanie TDD może dać pewien wgląd, spojrzeć na sprawy z innej perspektywy. Ale to wszystko zależy, to nie jest czarodziejska różdżka (wbrew temu co mówi Wujek Bob). - LukeJL 2016-12-05 16:33
@rav3n TDD nie usunie problemów z kiepską architekturą, co najwyżej pozwoli na refaktoring bez bólu - ale jak programista jest kiepski, to nawet mając 100% pokrycia testów nie będzie umiał zrefaktorować kodu. - LukeJL 2016-12-05 16:37
TDD ma swoje wady, ale według mnie przynajmniej cokolwiek daje niż robienie wszystkiego na pałę ;) Poza tym nikt nie powiedział, że TDD jest takie łatwo proste przyjemne i remedium na wszystko. Ale nie powiedzialbym, ze to zawsze overdesign, ja takiego poczucia nie mialem ;) - rav3n 2016-12-05 17:07
Myślę, że przede wszystkim nowicjuszom daje to trochę rozeznania w temacie. - rav3n 2016-12-05 18:03

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