Hej mirki spod tagu #programowanie Jestem ciekaw jak wielu z was używa TDD (tego prawdziwego TDD, nie samych unit testów). Zacząłem naukę phpunit, miałem zamiar wkręcać się w TDD, ale im więcej o tym czytam tym więcej wątpliwości...Np tu Jak to jest z tym unit testing u was? Używacie? Jeśli tak to w jakim zakresie? #php #phpunit #tdd
@gajowy_marucha: TDD brzmi wspaniale dopóki pracujesz sam albo w malutkim teamie. W dużych korpo, kiedy dedlajny czają się za rogiem, wymagania rosną z każdym dniem, technicznie nie ma siły na to żeby robić wszystko tak jak TDD nakazuje. Dużo częściej (z mojego doświadczenia) wychodzi "first code, then test", nie ważne jak bardzo się starasz
@paranoiddd: No właśnie też tak czuję. TDD wygląda dziwnie dla mnie (być może dlatego że tego nie znam), o ile pisanie unit testów do kodu do mnie przemawia tak TDD a jeszcze 100% coverage to już zupełnie nie...
@gajowy_marucha: ja staram stosować się do metodyki TDD(nie testuje wszystkiego), do tego wkręcam jeszcze testy funkcjonalne z BDD (naprawdę genialna sprawa :D, planujesz funkcjonalności bez dziwnego rozkminiania) no i staram się trzymać zasad DDD, ale tutaj szczerze muszę powiedzieć że brakuje mi doświadczenia.
@gajowy_marucha: mnie się zwykle wydaje, że wszyscy orędownicy TDD bardzo dawno nie pracowali jako szeregowy developer (czytaj: są jakimiś architektami, menadżerami itd) i lubią brzmieć mądrze ustawiając komuś innemu pracę ;) W realnym biznesie, nikt nie będzie sobie zaprzątał dupy testem, skoro klient chce funkcjonalności "na wczoraj"
@gajowy_marucha: Używam i widzę znaczne benefity w porównaniu do Test-Last. Mimo że pracuję w mocnym, zagranicznym teamie, nie wszyscy u mnie piszą Test-First. I problemem jest nawet nie tyle pokrycie testami czy projekt kodu. Czasami testy pisane Test-Last same zawierają błędy, tj. zdarza się, że nic nie testują. Zrobiłem ostatnio z tego powodu małą gównoburzę i mocno zaleciłem przynajmniej upewnienie się, że test zawodzi gdy np. popsujemy kod produkcyjny lub zmienimy
@gajowy_marucha: Dodatkowo: ta gównoburza z DHH i linkowanym przez Ciebie artykułem to nie jest taki zwykły "przykład". To bodaj największa gównoburza anty-TDD w ostatnich latach. Ze względu na to, jak dobrym programistą jest DHH. Bo że dużo plebsu jest przeciw TDD czy w ogóle przeciw testom automatycznym (trudno w to uwierzyć, ale jednak...) to akurat niestety standard.
Sam DHH jednak uważa, że testy automatyczne jak najbardziej trzeba pisać.
Mogę Ci jedynie doradzić krytyczne podejście do pisania testów. Jesli zaczynasz, postaw sobie jeden cel, niezmienny przez jakiś czas: pisać testy. Resztę optymalizuj. Gdy tylko zauważysz, ze coś Cię wkurza, ze test Cię spowalnia lub wydaje sie być kulą u nogi, analizuj powody. I staraj sie je poprawić.
Na początku to w ogóle testy idą trudno. Ale niewłaściwe jest porzucenie ich dlatego, ze napisanie jakichkolwiek testów
@gajowy_marucha: dużą częścią roboty programisty jest wjazd na cudzy kod i refaktoryzacja. W tym momencie oczywiście nie ma zbyt wiele miejsca na TDD. Ale i tak warto ogarnąć testy, jeśli ich nie ma. Przy kolejnym refaktorze to może być genialne ułatwienie. Chociaż ostatnio odszedłem w stronę pisania głównie funkcjonalnych (szybciej mi tak idzie), to każdy test na wagę złota :)
@gajowy_marucha: Ale przecież o to właśnie chodzi w TDD. Chyba nie uważasz, ze test-first polega na napisaniu wszystkich testów do danej funkcji najpierw, a potem dopisaniu kodu funkcji i spełnieniu tych testów?
To absolutnie niedopuszczalne, bezsensowne i SPRZECZNE z TDD / test first.
Programowanie techniką test-driven development wyróżnia się tym, że najpierw programista zaczyna od pisania testów do funkcjonalności, która jeszcze nie została napisana. Na początku testy mogą nawet się nie kompilować, ponieważ może nie być jeszcze elementów kodu (metod, klas) które są w testach użyte.
Chyba że źle to zrozumiałem lub my się nie zrozumieliśmy... Całość tu
@gajowy_marucha: No to masz pierwszy przykład gigantycznego zonka, na który trafiłeś. To kompletnie nie tak, jak to zinterpretowałeś. Choć wklejony przez Ciebie cytat tego nie tłumaczy.
Owszem, zaczynasz od pisania testu. Ale testy i kod piszesz PO KAWAŁECZKU. To JEST takie test-as-you-go, z tym tylko zastrzeżeniem, że najpierw zaczynasz od napisania kawałka testu, a potem piszesz kawałek kodu, który go implementuje.
Opiszę cykl działania w TDD. Zaczynasz od wymyślenia przypadku testowego,
@Sh1eldeR: To ma sens... dzięki. Na pewno trzeba doświadczenia, jak ze wszystkim, żeby stosować TDD prawidłowo. No nic, wracam do czytania, dzięki jeszcze raz.
Ogólnie: TDD z pętlą red->green->refactor (as you go) robię przy nowych klasach, które sam projektuję. Jeśli klasa ma być pośrednikiem do zewnętrznej biblioteki, to różnie bywa, bo czasem nie do końca wiem jak to powinno wyglądać, więc łatwiej jest mi to ogarnąć „na żywca”
60zl za brak reklam na Instagramie - kogoś #!$%@? xD Ja rozumiem te wszystkie opłaty za serwisy streamingowe itd, ale #!$%@? 60zl za jakiegos Instagrama, żeby sobie bez reklam posty i story oglądać? #instagram #facebook
Jestem ciekaw jak wielu z was używa TDD (tego prawdziwego TDD, nie samych unit testów).
Zacząłem naukę phpunit, miałem zamiar wkręcać się w TDD, ale im więcej o tym czytam tym więcej wątpliwości...Np tu
Jak to jest z tym unit testing u was? Używacie? Jeśli tak to w jakim zakresie?
#php #phpunit #tdd
do bdd korzystam z http://codeception.com/
Używam i widzę znaczne benefity w porównaniu do Test-Last. Mimo że pracuję w mocnym, zagranicznym teamie, nie wszyscy u mnie piszą Test-First. I problemem jest nawet nie tyle pokrycie testami czy projekt kodu. Czasami testy pisane Test-Last same zawierają błędy, tj. zdarza się, że nic nie testują. Zrobiłem ostatnio z tego powodu małą gównoburzę i mocno zaleciłem przynajmniej upewnienie się, że test zawodzi gdy np. popsujemy kod produkcyjny lub zmienimy
Dodatkowo: ta gównoburza z DHH i linkowanym przez Ciebie artykułem to nie jest taki zwykły "przykład". To bodaj największa gównoburza anty-TDD w ostatnich latach. Ze względu na to, jak dobrym programistą jest DHH. Bo że dużo plebsu jest przeciw TDD czy w ogóle przeciw testom automatycznym (trudno w to uwierzyć, ale jednak...) to akurat niestety standard.
Sam DHH jednak uważa, że testy automatyczne jak najbardziej trzeba pisać.
Trzeba jeszcze powiedzieć,
Co to znaczy test-as-you-go?
Mogę Ci jedynie doradzić krytyczne podejście do pisania testów. Jesli zaczynasz, postaw sobie jeden cel, niezmienny przez jakiś czas: pisać testy. Resztę optymalizuj. Gdy tylko zauważysz, ze coś Cię wkurza, ze test Cię spowalnia lub wydaje sie być kulą u nogi, analizuj powody. I staraj sie je poprawić.
Na początku to w ogóle testy idą trudno. Ale niewłaściwe jest porzucenie ich dlatego, ze napisanie jakichkolwiek testów
Ale przecież o to właśnie chodzi w TDD. Chyba nie uważasz, ze test-first polega na napisaniu wszystkich testów do danej funkcji najpierw, a potem dopisaniu kodu funkcji i spełnieniu tych testów?
To absolutnie niedopuszczalne, bezsensowne i SPRZECZNE z TDD / test first.
Chyba że źle to zrozumiałem lub my się nie zrozumieliśmy... Całość tu
No to masz pierwszy przykład gigantycznego zonka, na który trafiłeś. To kompletnie nie tak, jak to zinterpretowałeś. Choć wklejony przez Ciebie cytat tego nie tłumaczy.
Owszem, zaczynasz od pisania testu. Ale testy i kod piszesz PO KAWAŁECZKU. To JEST takie test-as-you-go, z tym tylko zastrzeżeniem, że najpierw zaczynasz od napisania kawałka testu, a potem piszesz kawałek kodu, który go implementuje.
Opiszę cykl działania w TDD. Zaczynasz od wymyślenia przypadku testowego,
O ile kojarzę, tu masz niezły przykład TDD na żywo, zapodany przez samego Uncle Boba:
https://www.youtube.com/watch?v=D9GQ9nBHhIc&t=1h6m (EN)
* http://www.wykop.pl/wpis/11677499/gdy-testujecie-swoje-aplikacje-w-laravel-piszecie-/
* http://www.wykop.pl/wpis/11296794/programowanie-python-luzneprzemyslenia-mireczki-mo/
* http://www.wykop.pl/wpis/13509219/
* http://www.wykop.pl/wpis/11501778/symfony2-php-jakas-literatura-o-pisaniu-testow-jed/
* http://www.wykop.pl/wpis/7831932/szef-poprosil-zebym-sie-ustosunkowal-programowanie/
---
Ogólnie: TDD z pętlą red->green->refactor (as you go) robię przy nowych klasach, które sam projektuję. Jeśli klasa ma być pośrednikiem do zewnętrznej biblioteki, to różnie bywa, bo czasem nie do końca wiem jak to powinno wyglądać, więc łatwiej jest mi to ogarnąć „na żywca”