Czyli kod operujący na ORM powinie być izolowany aby usprawnić testy integracyjne.
Tu nawet nie o testy chodzi, oddzielenie pobierania danych od ich przetwarzania to po prostu stosowanie zasady SRP.
No dobra ale jeśli chcę wyświetlić w view wynik zapytania to mogę wstrzyknąć do kontrolera bezpośrednio repozytorium, dao, czy muszę tak jak to większości przypadków widzę zrobić na to wraper w postaci jakiegoś serwisu, który i tak nie ma żadnej logiki..?
Ciekawe, że piszesz o większości przypadków, bo ja raczej widzę idiotyczne wstrzykiwanie "repozytoriów" bezpośrednio do kontrolerów. Szczęściarz z Ciebie.
Ja bym zrobił serwis, który operuje na sesji ORMa i używał go z kontrolera. Wszelkiego rodzaju testy przy takim podejściu pisze się łatwo.
Widzę że nie chcesz mi odpowiedzieć na ostatnie pytanie.
No, to straszne, że nie odpisałem aż przez 49 minut. :D
To nie lepiej będzie najpierw stworzyć zaślepkę w postaci ORM w unit teście a potem jeszcze raz to przetestować z testem integracyjnym.
I jaki zysk da test jednostkowy z zamockowanym ORMem w tak trywialnym przypadku? Żadnego, bo cała logika jest oparta na tym, co faktycznie zwróci baza.
Zaoszczędzając na dodatkowej warstwie przecież po coś wstrzykuje tego ORM'a.
Zgaduję, że wstrzykujesz po to, żeby nie tworzyć zapytań SQL ręcznie.
Czyli jeśli chcę sprawdzić czy ORM wypluł 10 wierszy z 20 (przed chwilą to napisałem i chcę sprawdzić czy działa.) to muszę do tego użyć realnej bazy ? To ma być pragmatyczne ?
Tak.
No chyba, że piszesz testy, żeby pisać, a nie po to, żeby się upewnić czy aplikacja działa.
Co mnie interesuje dokładność liczbowa w zakresie 6 zer. Jak to dokładność przechowywania daty? Chodzi ci o pułapkę milenium? To jakaś baza nie obsługuję UTC I jednego z 4 najpopularniejszych typów formatowania daty? To jak ty zapisujesz tą datę do bazy?
Pułapka millenium, mocne. :P
Nie mam pojęcia o jakich 4 typach formatowania mówisz. Generalnie różne SZBD oferują różne typy danych do przechowywania informacji o czasie. Typy te mogą mieć różne dozwolone zakresy i różne dokładności (np. datetime w MSSQL przechowuje dość nietypowo, bo z dokładnością do 1/300 sekundy). I wypadałoby też, aby programista dobrał typ do danych jakie zamierza przechowywać, a nie zawsze wybierał ten "najlepszy", który przy okazji zajmuje najwięcej miejsca i najwolniej się z niego korzysta.
No i teraz, jeśli program zapisze dane do bazy z jakąś dokładnością, ORM je jakoś skonwertuje, a baza narzuci swoje ograniczenia, to może się okazać, że różnice są na tyle istotne, że test na fejkowej bazie przejdzie, a ten na prawdziwej nie. Albo w drugą strone, SQLite może ograniczyć dane bardziej niż prawdziwa baza. A co jeśli problemem nie będzie baza tylko sterownik ORMa do niej będzie miał jakiegoś buga? A do tej drugiej będzie ok? Jednostkowe testy operacji na bazie mają tyle możliwości na bycie fałszywymi, że są po prostu zupełnie bezsensowne.
Nie wiem po co piszesz swoje aplikacje, ale ja po to, żeby działały. A testy piszę po to, żeby upewnić się, czy aplikacja robi to, co chcę żeby zrobiła. Jeśli coś zapisuję, to chcę odczytać to samo. Lepiej gdy sprawdzę to ja niż użytkownicy na produkcji.