Wpis z mikrobloga

@mer: Tak samo jako wszystkich innych kontrolerów – podmieniasz/mockujesz/stubujesz wszystko z czego korzysta kontroler, tak, żeby móc go przetestować w izolacji.

Z bazki korzystasz zapewne przy pomocy repozytorium – tak więc test komunikacji z bazką to oddzielna rzecz niż test kontrolera.
@mer: > W sumie to miałem na myśli testy funkcjonalne

Nawet tutaj podmień sobie wszelkie manipulacje z bazką na rodzaj InMemoryRepository – po co ma Cię bazka spowalniać? Nie ma sensu testować bazki, testujesz swoją aplikację.
testy funkcjonalne


@mer: a to lepiej, aczkolwiek dla mnie to dalej bez sensu - bo tak naprawde jak masz przetestowaną swoją logike, to potem jedyne co testujesz to biblioteke/framework..
@MacDada: Ogólnie chciałbym zacząć pisać testy jednostkowe a w dokumentacji jest to opisane już dla kumatych, od czego powinienem zacząć?
Zakładamy że mam akcję która pobiera coś z repo doctrine, jak napisać dla takiej akcji test?
Na chwilę obecną nie mam żadnych własnych klas,bundli etc.Jest sens ogólnie pisać takie testy w takim przypadku?
@mer: każdy test zaczynasz od odpowiedzi na pytanie - co SWOJEGO chcesz przetestowac.
Nie ma sensu testowac Doctrine czy innego framework.
Jesli chcesz przetestowac, czy Doctrine pobierze cos z bazy - to rownie dobrze mozesz napisac assert(true) - taka sama wartośc ma ten test.
@mer: krzykaczowi chodzi o to, ze doctrine jest przetestowany i nie ma sensu testowac go drugi raz. Jesli piszesz metode ktora wybiera najmniejsza liczbe i pobiera z bazy ten element, to testujesz tylko wybieranie liczby a nie samo pobieranie.
@mer: Jak masz całą logikę w kontrolerze to już tutaj jest błąd – mieszanie warstw, łamanie SRP.

Czemu to błąd? Bo im więcej logiki skupionej w jednym miejscu, tym trudniej się to testuje. Kontroler odpowiada za komunikację po warstwie HTTP – zdobywa Request, odpala warstwę modelu, żeby coś zrobiła, zwraca Response z wynikiem.

Wtedy testując kontroler sprawdzasz czy poprawnie się komunikuje (np czy dobrze odczytał dane z Requesta i uruchomił
@MacDada: @kmicolo: Mam metodę do uploadu plików, podobną do tej w cockbooku, na triggerach postupdate i postpersist, jest sens pisać test? Ostatnio często coś w niej zmieniam i przydało by się wiedzieć czy zapisuje plik tam gdzie chcę na przykład.
@MacDada: Dzięki za esej, dziwi mnie że wcześniej na > @Template nie wpadłem, wygląda bardzo legitnie.Bardzo ułatwi mi to budowanie API na przyszłość.Jeżeli chodzi o MVC to staram się
@Atomic_Cookie: Jakiegokolwiek wyjątku z doctrine, nie chcę klientowi końcowemu udostępniać info($e->getMessage()).A na FlashBagach mam ładne wyświetlanie błędów dlatego 404 nie pluje ;)
@mer: Ale doctrine nie ma prawa się #!$%@?ć bez powodu. Jedyne przez co może sie wywalić to błąd programisty. Jedyny błąd jaki w takim razie może wypluć to NotFoundException. I wtedy powinna się pokazać strona 404. A to $e->getMessage() masz tylko w środowisku dev.
@mer: Jeżeli dobrze napisałeś projekt to nie ma opcji, żeby jakikolwiek odnośnik odnosił się do nieistniejącego zasobu. Jedyna możliwość jest taka, że użytkownik sam w to wejdzie - i wtedy powinieneś wywalić mu 404.
@mer: Nie jest złe, ale po prostu zbędne. Popatrz na to z tej strony -> ktoś wyśle formularz do nieistniejącej kategorii i dostanie napis 'Błąd blablabla' i nie wie co spowodowało ten błąd. Jak będzie 404 to będzie wiedział, że taka kategoria po prostu nie istnieje. I nie ma sensu się bawić w wypadku 404 w jakieś flashbagi. Po prostu wywalasz NotFoundException i resztą zajmuje się framework, a użytkownik wie, że
@mer:

Tak jak wspomniał @Atomic_Cookie – wywal tego try catcha. Co się stanie jeśli np wybuchnie Ci bazka przy zapisie? Użytkownikowi pojawi się strona błędu (http error 500), a strona błędu może np robić redirecta do strony głównej po 10–u sekundach JSem.

Czemu więc tego nie przechwycić? Bo user dostaje info, że coś poszło nie tak jak należy, ale TY też dostajesz to info – zostaje zapisane do logów, chyba, że