Test Driven Development (TDD) a commity

Test Driven Development (TDD) a commity
bagietMajster
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 446
2
Riddle napisał(a):
bagietMajster napisał(a):

A piszesz testy? Nie z TDD, tylko czy piszesz testy w ogóle np. testy jednostkowe, już po fakcie?

Tak, piszę testy jednostkowe po tym jak zrobię zadanie.

Czyli piszesz testy już po napisaniu feature'a?

To mam pytanko do Ciebie:

  • Jaki masz code coverage'a?
  • Ile z tego code coverage jest puste, a ile faktycznie pokrywa kod? (tak że testy failują jak znajdą buga w tym miejscu)
  • Jak często podczas pisania aplikacji uruchamiasz ją żeby sprawdzić czy działa nadal wporzo?
  • Jak często, kiedy natrafiasz na miejsce trudne do przetestowania, po prostu stwierdzasz "aa, dobra" i zostawiasz to miejsce nieprzetestowane?
  • Czy można się spodziewać że 80% Twoich testów to są testy jakichś helperów, a faktyczne mięcho Twojej aplikacji jest nieprzetestowane?
  • Nie badamy tego, mój zespół podobnie jak jak uważamy to za pustą statystykę. Jak miałbym celować to między 50 a 90%.
  • j/w + nie chce mi się przeglądać paruset testów w każdym z serwisów
  • Nie rozumiem pytania, chyba oczywiste że cały czas podczas developmentu. Nie robię ficzerów na strzała tylko cały czas coś sprawdzam zwłaszcza przy odczycie z bazy danych i SQL builderze żeby kontrolować co wypluwa. Potem jak robię comita to CI/CD odpala mi unity + integraty więc mam feedback czy coś działa czy nie.
  • Zazwyczaj pytam kogoś czy ma pomysł jak to przetestować żeby sobie włosów z głowy nie wyrywać, ale jak się nie da to się nie da i pomijamy. Nigdy sam nie celowałem w 100% coverage bo jest to syzyfowa praca.
  • Pokrycie moich testów idzie łeb w łeb w Twoimi edycjami tematów tutaj na forum. Chociaż ostatnio widzę spadek formy.
Riddle
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 10227
2
bagietMajster napisał(a):
  • Nie rozumiem pytania, chyba oczywiste że cały czas podczas developmentu. Nie robię ficzerów na strzała tylko cały czas coś sprawdzam zwłaszcza przy odczycie z bazy danych i SQL builderze żeby kontrolować co wypluwa. Potem jak robię comita to CI/CD odpala mi unity + integraty więc mam feedback czy coś działa czy nie.

Czyli w sumie wykonujesz testy manualne podczas developmentu. Jestem ciekaw jaki % Twojej pracy idzie na to "sprawdzanie", skoro robisz to ciągle. Obstawiam że około 50%? Co stoi na przeszkodzie żeby te 50% czasu, zamiast na testy manualne podczas pracy przeznanczyć na napisanie testów najpierw? Wtedy nie musiałbyś w ogóle sprawdzać manualnie Twoich programów.

bagietMajster napisał(a):
  • Zazwyczaj pytam kogoś czy ma pomysł jak to przetestować żeby sobie włosów z głowy nie wyrywać, ale jak się nie da to się nie da i pomijamy. Nigdy sam nie celowałem w 100% coverage bo jest to syzyfowa praca.

To bardzo brzmi jak trudności z testowaniem, których po prostu by nie było gdybyś stosował TDD.

Oczywistym jest, po tym co mówisz, że nie praktykowałeś TDD, a jednak masz negatywne opinie na ten temat. Spróbuj jednego dnia w jakimś prywatnym projekcie do tego podejść, może zmienisz zdanie?

bagietMajster
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 446
0
Riddle napisał(a):
  • Zazwyczaj pytam kogoś czy ma pomysł jak to przetestować żeby sobie włosów z głowy nie wyrywać, ale jak się nie da to się nie da i pomijamy. Nigdy sam nie celowałem w 100% coverage bo jest to syzyfowa praca.

To bardzo brzmi jak trudności z testowaniem, których po prostu by nie było gdybyś stosował TDD.

Nie róbmy z k****y logiki, jeśli jest element systemu który ciężko przetestować albo przez złożoność danych wejściowych albo przez architekturę to co zmiana podjęcia na TDD zmieni? Problem w architekturze przestanie występować? Obiekt nie będzie posiadać tylu propów? No ludzie kochanii...

Riddle
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 10227
3
bagietMajster napisał(a):

Nie róbmy z k****y logiki, jeśli jest element systemu który ciężko przetestować albo przez złożoność danych wejściowych albo przez architekturę albo sytuację wynikająca nie z stworzonego kodu to co zmiana podjęcia na TDD zmieni? Problem w architekturze przestanie występować? Obiekt nie będzie posiadać tylu propów? No ludzie kochanii...

No właśnie zdziwiłbyś się jak bardzo TDD może w tym pomóc.

TDD nie znaczy "write tests first, just because". TDD znaczy "test driven development" - programowanie sterowane testami. TDD to technika projektowa, w której dzięki testom napisanym wcześniej, powstały kod ma inny kształt, lepszy design, i z reguły też jest bardziej spójny i modularny.

Więc jak najbardziej kod powstały w TDD jest dużo prostszy w testowaniu, i jak najbardziej powstała architektura wtedy jest łatwiejsza i prostsza.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.