@kilogram: https://github.com/sarven/unit-testing-tips

@GeDox: W takim wypadku mockujesz funkcję zapisu do bazy danych i nie wykonujesz zapytania tylko sprawdzasz czy poprawny typ danych przyszedł i odpowiednie operacje się wykonały

@GeDox: Jeżeli chcesz sprawdzać bazę to musisz pisać zapytania ręcznie. Jeżeli nie chcesz pisać zapytań ręcznie to rozwiązanie podrzucił @Hepar. Mockowanie funkcji zapisu do bazy i sprawdzanie przed zapisaniem czy przyszło wszystko ok.

Tym razem poruszyłem temat testowania przy użyciu PHPUnit i Dockera.

@robdevblog: ja bym powiedział, że poruszyłeś temat tworzenia skryptu sh i aliasów ¯\_(ツ)_/¯

btw. czemu skrypt służący do odpalania testów nazwałeś "app.sh" a nie np. "test.sh" albo "run-tests.sh" co by sam za siebie mówił do czego służy?

@tylko_na_dole: nie, zapomnij o istnieniu kontenera w 90% przypadków przy pisaniu unitów. Używaj metody setUp aby jednorazowo tworzyć testowaną klasę i mocki bez kopiowania kodu. Trzymaj się standardu nazewnictwa: testFirst_Success() - mieszane dwa style. Dbaj o to żeby test miał nazwę adekwatną do tego co testuje - ten przykład jest dosyć abstrakcyjny, ale już tutaj dopisek Success gryzie; przykładowo gdybyś miał klasę która jedyne co robi to dodaje komentarz, toPokaż całość

@tylko_na_dole: nie, w testach jednostkowych nie powinno być w ogóle kontenera i frameworka
do tego testowanie repozytoriów w testach jednostkowych mija się z celem, bo głównie będziesz testował mocki, albo czy dobrze działają natywne elementy języka(typu typowanie, wywołania metod, ustawianie propertiesów itp)

takie rzeczy lepiej testować integracyjnie, czy to na realnej bazie, czy na jakimś sqlite albo inmemory jeśli trwa to za długo, ale tego drugiego bym unikał, jeśli trwaPokaż całość

@tylko_na_dole: Oczywiście, że sam powinieneś tworzyć obiekty, które są przedmiotem testów jednostkowych.

Jak wyciągasz rzeczy z DIC, to nie robisz testów jednostkowych.

@tylko_na_dole: jest publiczny kontener do testów w nowszym SF
https://symfony.com/blog/new-in-symfony-4-1-simpler-service-testing
poszukaj jak w WebTestCase ustawiany jest self::$container jeżeli chcesz się do niego dostać bez dziedziczenia po WebTestCase.
No i tak jak przedmówcy jeżeli masz możliwość to testuj bez odpalania aplikacji jeżeli to testy jednostkowe.

@Hipodups: + static mocks - unit podstawi wtedy swoją klasę przez autoloader i mock statica zadziała, warunek zaznaczony w dokumentacji że nie możesz "użyć" tej klasy zanim postawisz mocka

@mariecziek: Szukaj raczej ogólnie o testach jednostkowych, a nie stricte pod PHP. Filozofia pisania testowalnego kodu niczym nie różni się w PHP i innych językach jak Java czy inny C#.

Generalnie nie chodzi o to, jak pisać testy, tylko jak pisać kod, żeby się dało testy napisać.

No i jeszcze pytanie, czy interesuje Cię tylko pisanie unit testów, czy może jeszcze do tego TDD.

@mariecziek: Podstawowa kwestia, jeśli chodzi o testowalność kodu, to Dependency Inversion (Inversion of Control) poprzez Dependency Injection + interfejsy.
W momencie, gdy zależności przekazujesz z zewnątrz, jesteś w stanie je łatwo zmockować w teście, lub podstawić inną implementację zależności z warstwy infrastruktury (np. implementacja "in-memory" jakiegoś storage'u), dzięki czemu nie jesteś uzależniony od bazy etc.

Z tego też wynika dlaczego Service Locator (wstrzykiwanie całego DIC zamiast poszczególnych zależności) to antypattern.Pokaż całość

@Lethal_Jelly: jak dużo masz plików w projekcie? Spróbuj dodać addUncoveredFilesFromWhitelist="false" do tagu whitelist, wtedy będzie monitorował tylko pliki, które testujesz. Dodatkowo zobacz jak długo wykonują się na innym komputerze - może masz coś spieprzone w konfiguracji. Ogólnie coverage w phpunit wykonuje się dużo dłużej niż normalne testy, ale 5h to jakiś hardcore. Może masz włączone profilowanie?

Jeśli chodzi o obsługę biblioteki samej w sobie, to dokumentacja - tu nie ma dużo filozofii.
Jeśli chodzi o pisanie testów, to łatwiej będzie Ci znaleźć coś language agnostic lub po prostu w innym języku (Java/C#). Filozofia jest zawsze ta sama, a że PHPUnit ma podobne api jak wszystkie te xUnity, to nie będziesz miał problemów z przełożeniem tego na PHP.

@gajowy_marucha: Ponieważ 3 == true, ale już 3 !== true? Tak tylko strzelam

@gajowy_marucha: zostaw #php i zacznij programować

@Uparciuch: Hahahaha xD

Pokaż spoiler

@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 wartość oczekiwaną z 42 na 43.

Teraz, nie uważam bynajmniej, że TDD jest łatwe. Nie jest łatwo pisać dobre testy. Łatwo pisać syfne testy. To tak jak z kodem.

Dobre testy wydają się bardzo nieszczególne gdy się je czyta. Ale trudno jest dobrać odpowiedni poziom DRY, odpowiedni poziom przejrzystości kodu i "wyglądania jak przykładowe użycia" (to kłóci się często z DRY), odpowiedni poziom mockowania (nie mockować za dużo) itp. itd. Zresztą, ludzie popełniają dużo prostsze błędy przyPokaż całość

@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, czyli tworzysz sobie pusty TestCase / blok it() (w BDD), czy cokolwiek innego. Nadajesz mu nazwę która opisuje funkcjonalność, którą będzie testował. Zauważ, że ten test nie musi sprawdzać wszystkiego, co robi jakaś jedna metoda. Może sprawdzić tylko kilka rzeczy. Jeśli piszesz kalkulator, to jednym testem będzie "dzieliDwieLiczby", a osobnym "wyrzucaWyjątekDzieleniaPrzezZero", mimo że to ta samaPokaż całość

@gajowy_marucha: http://it-ebooks.info/book/3555/
Kompletnie wyjaśnione, jak gdzie i po co.

@gajowy_marucha: Ja chyba od tego zaczynałem (w każdym razie wygląda znajomo): https://jtreminio.com/2013/03/unit-testing-tutorial-introduction-to-phpunit/
Wujek Bob często pisze o testowaniu - konkretów może mało, ale często ciekawy punkt widzenia i przyjemnie się go czyta: https://blog.8thlight.com/uncle-bob/archive.html

@ghost1511: w folderze projektu (D:\xamppphp5.5.19\htdocs\e-shop\tests ) utwórz plik cmd z komendą

php phpunit.phar --testsuite "IntegrationTests" -c "%~dp0configuration.xml" albo z linii komend uruchamiaj komendą php phpunit.phar --testsuite "IntegrationTests" -c "%CD%configuration.xml" wtedy zadziała na różnych ścieżkach i komputerach.

wiem, że Windows nie nadaje się do #webdev

@ghost1511: co #!$%@? ?

@saul: Czyli ogólnie działa (testuje), tylko ktoś uważa, że test powinieneś inaczej napisać (w inny sposób użyć dataprovidera)?

@zergqq2: jak nie duże miasto to tak 2,5-3k netto. Poprzeglądaj tą grupę: https://www.facebook.com/groups/403156189820397/ wszystkei oferty mają widełki

@zergqq2: na start 3, 3,5k i jeśli masz zapał do nauki i tworzysz dobre gówno, to starałbym się o podwyżkę po 2 miesiącach

Gdzie widzisz problem? Do zmiennej przypisujesz wartosci, nastepnie odpalasz sobie taki setter i sprawdzasz jakis assert, exception czy cokolwiek chcesz.

@ghost1511: Jak nie masz gettera to testuj metody, które używają właściwości (settera testujesz pośrednio). Generalnie taki setter z walidacją/parsowaniem to side effect i powinno się tego unikać.

@singollo: Co tdd ma do brakujących bibliotek?

@singollo: Testy funkcjonalne zawsze mozna zrobic jakims phantomjs :P