Dlaczego to jest słabe? testujesz realną ścieżkę w aplikacji
Bo higiena wymaga, aby logika biznesowa była niezależna od infrastruktury. Wtedy można ją przetestowania jednostkowo bez cudowania. I nawet przenieść do innego rodzaju aplikacji, bez problemu.
Test controller logic in ASP.NET Core
Jaki zysk daje zepsucie architektury i testowanie kontrolerów, zamiast implementacji zgodnie z MVC i umieszczeniem logiki w modelu, a nie w kontrolerach?
Nie oszczędzi się w ten sposób na ilości kodu ani na szybkości jego pisania. Więc jaki jest cel?
Tak samo z fakowaniem db do testów - w 99% nie ma sensu używać prawdziwej, ale czasem zdarzy się, że np. po zmianie bazy takie testy wykryją Ci jakiegoś buga typu: niestandardowy znaczek nagle nie chce się dać zapisać, a wcześniej działał i był używany.
No i jak niby sprawdzisz zapis problematycznych znaków do bazy w testach jednostkowych?
ja widziałem coś takiego jako parametr metody repo.
List<Expression<Func<TEntity, object>>> includeProperties
Tylko czemu logika biznesowa ma mówić repozytorium jak korzystać ze źródła danych? Czemu logikę biznesową coś takiego jak include w ogóle ma obchodzić? Przecież to jest cieknąca abstrakcja, nic więcej.