Czy ktoś jeszcze stouje TDD dla siebie jak i pracy?
Czy już lepiej tego nie używać i nie uczyć się?
1
0
Wiele osób. Czemu miało by nie być używane?
0
AreQrm napisał(a):
Czemu miało by nie być używane?
Bo trzeba się tego uczyć, a to oddala załapanie się do pierwszej pracy jako junior (główny temat tego forum) i kolejny najistotniejszy punkt: PROFIT! ;)
0
Nie wszędzie używa się TDD a od Juniorów zwykle nie wymaga się Bóg wie czego. Nawet nie zawsze od "Regulara" się wymaga praktycznej znajomości/dośw w TDD... bo nie wszędzie je stosują.
8
AreQrm napisał(a):
Nie wszędzie używa się TDD a od Juniorów zwykle nie wymaga się Bóg wie czego. Nawet nie zawsze od "Regulara" się wymaga praktycznej znajomości/dośw w TDD... bo nie wszędzie je stosują.
Niezupełnie - TDD wymaga się wszędzie i od wszystkich, tak samo jak SOLID, kreatywności i pięciu lat doświadczenia we frameworkach, które pojawiły się rok temu.
Tylko potem i tak tworzy się nietestowalne spaghetti w 15 letnim projekcie, bo tego chcą klienci i kierownicy.
1
Bo trzeba się tego uczyć,
przede wszystkim trzeba się nauczyć tworzyć testy unitowe. Niezależnie od tego, czy się stosuje TDD czy nie, będzie potrzeba pisania testów jednostkowych.
TDD to po prostu specyficzna metoda pisania testów jednostkowych (najpierw testy, potem implementacja), nie zawsze się ją stosuje. Często się robi najpierw implementację, potem się dopisuje testy (kwestia przekonań, podejścia - czy TDD jest dobre, to można się spierać długo). Ale tak czy siak pisania testów jednostkowych wcześniej czy później będziesz musiał się nauczyć.
a to oddala załapanie się do pierwszej pracy jako junior
moim zdaniem przybliża. Jak cię będą pytać na rozmowie o testy to jeśli powiesz "nigdy nie pisałem" będziesz od razu na gorszej pozycji niż jak powiesz "owszem, pisałem testy jednostkowe, robiłem to w ten i ten sposób (zwykle są gotowe frameworki do unit-testów).
0
A jaki framework polecacie do testów jednostkowych w C# tak by integrowało się z Visual Studio.
xUnit? NUnit?
1
Krzywy Kot napisał(a):
Czy już lepiej tego nie używać i nie uczyć się?
Co? Jasne, że warto tego używać. Ja osobiście używam kiedy tylko mogę. Wymaga to wprawy, doświadczenia, zajmuje więcej czasu, trzeba to poczuć, ale uważam, że jest to prawidłowy kierunek, ponieważ znacznie podwyższa jakość projektu i rozwija Ciebie jako programistę. TDD da się stosować nie tylko w najnowszych technologiach i projektach. Z ciekawostek mogę powiedzieć, że udało mi się zastosować TDD w 15-letnim legacy kodzie. :D
Wiadomo, że nie każdy task można zrobić zgodnie z książką, ale warto dążyć do jak najlepszych rozwiązań.
0
Szczerze mówiąc czystego TDD, polegającego na tym, że nie piszemy kodu produkcyjnego przed napisaniem testów - nie spotkałem w firmach, w których robiłem. W większości projektów jest jakieś 50-80% pokrycia.
4
50-80% pokrycia jest zwykle ok, ale w TDD nie chodzi tylko o pokrycie. Wiele firm myśli, że używa TDD, podczas gdy tak naprawdę używa unit-testów. Nawet pisanie testów przed kodem, to jeszcze nie jest TDD, tylko raczej TBD (Test Before Development).
W TDD chodzi głównie o to, że piszemy testy, które wynikają wprost z wymagań, a następnie piszemy najprostszy (i zwykle brzydki) kod, który przechodzi te testy. Potem kod refaktoryzujemy np. zauważamy wspólne elementy i uogólniamy implementację, i tak w kółko aż do spełnienia wszystkich wymagań. Kod ma być zależny i całkowicie podporządkowany testom. Ma to rzekomo powodować, że powstanie lepiej zaprojektowany i lepiej przetestowany kod, niż robiąc to metodą tradycyjną, tj: iterując [projekt -> implementacja -> testy]. Dobry projekt w TDD powinien się "wyłonić" magicznie sam w procesie refaktoryzacji kodu przechodzącego testy.
Rozumiejąc TDD według powyższej definicji, nie używamy TDD w naszej firmie. Z mojego doświadczenia (i doświadczenia kilku kolegów), przy dostatecznie trudnych projektach niestety TDD nie działa. Tzn. nie działa ta część związana z powstawaniem lepszego projektu. Część związana z testowaniem działa, ale do tego nie trzeba TDD, tylko po prostu testów, testów i jeszcze raz testów. Pisanych przed czy po, czy w trakcie nie ma znaczenia. Ważne by były.
Przykład: piszemy rozproszony system plików. Jakbyśmy zaczęli pisać testy od najbardziej podstawowych funkcji, aby szybko dojść do minimalnego działającego prototypu, który możemy pokazać klientowi, to przez pierwszy rok projektu wszystkie testy dałoby się przechodzić budując kod działający jak scentralizowany system plików (ba, można by oddelegować po prostu wszystko do ext4 i voila - nasz system działa). Natomiast na końcu projektu, po dorzuceniu paru pozafunkcjonalnych wymagań takich jak np. odporność na awarie czy skalowalność, okazałoby się że musimy wyrzuć cały kod i zacząć od początku, bo to co napisaliśmy, do niczego się nie nadaje, mimo że przechodzi milion unit-testów.
Może to skrajny przypadek, ale nawet w prostszych sytuacjach, na poziomie powiedzmy jednej klasy, często lepiej jest chwilę dłużej przemyśleć wszystkie wymagania, napisać od razu porządny kod i zestaw testów, niż pisać testy, brzydki kod, a następnie go poprawiać aż do skutku. Po prostu projektując na początku i pisząc od razu dobry kod, mniej czasu marnuje się na poprawianie.
1
Czy ktokolwiek zadał sobie może trud sprawdzenia opłacalności zastosowania TDD w tworzeniu i rozwijaniu oprogramowania pod względem ekonomicznym? I nie chodzi tu tylko o czasochłonność ale może przede wszystkim o zagadnienia związane z tym jak często statystycznie tacy programiści popełniają błędy (i chodzi mi przede wszystkim o to) i czy przypadkiem nie jest to tak, że o tych testach to się tak tylko mówi żeby to wszystko ładnie wyglądało a w praktyce jest inaczej.
Oczywiście nie neguję tutaj wcale słuszności sprawdzania poprawności przy użyciu AssertEquals czy innych podobnych metod, jednak mógłbym tu podać co najmniej kilka przykładów na to, że nie wszystko da się w ten sposób sprawdzić.
Tu jest twierdzenie, że TDD jest przystanią dla słabych programistów:
http://www.throwexception.pl/tdd-przystan-slabych-programistow/
Czasami przeglądałem nawet strony niektórych firm które wręcz chwalą się przed potencjalnymi klientami tymi testami, zastanawiam się czy nie jest to tylko taki sprytny zabieg marketingowy - klienta który często nie zna się na programowaniu w ogóle nie obchodzi czy są testy czy nie.
0
Abstrahując od TDD z którym mam małe doświadczenie, brak testów jest bardzo kiepskim pomysłem. Podanych przed czy po. Tak samo źle wpływa na pracę i jakość oprogramowania pod względem błędów /ich braków