Implementacja najlepszych praktyk .NET Full Webdev na przykładzie własnej aplikacji pisanej po godzinach

Test controller logic in ASP.NET Core

Hihi, kontrolerów nie testujemy niuniuniu... :D :D :D :) :)

Testujemy domenę Unit testowo :D :D :P

Potem testujemy sobie albo adapter na prezentacje czy adapter na web :D :D albo testujemy sobie akceptacyjnie albo funcyjnie serwis aplikacyjny albo domenowy :D :D :D

Jak ludzie radzą sobie z Includami używając repo?
Czy taki Helper jest repem?

Po prostu piszą repo a nie helpery, hihihi :D :D :D :))))))

Repo jest helperem ale petarda co nie ? :D :D :D :D :) :) :)

WeiXiao napisał(a):

Jak ludzie radzą sobie z Includami używając repo?

O ile dobrze Cie zrozumiałem to:
ja widziałem coś takiego jako parametr metody repo.

List<Expression<Func<TEntity, object>>> includeProperties

A w tej metodzie

includeProperties.ForEach(i => { query = query.Include(i); });

gdzie Query to było

IQueryable<TEntity> 

@szydlak:

A jak pójdziemy krok dalej? :D

.Include(x => x.Something)
.ThenInclude(x => x.SomethingOtherA)
.Include(x => x.Something)
.ThenInclude(x => x.SomethingOtherB)
.Include(x => x.OtherSomething)
.ThenInclude(x => x.WTF)
.ThenInclude(x => x.WTF_2)

WeiXiao napisał(a):

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?

szydlak napisał(a):

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.

@somekind:

Jaki zysk daje zepsucie architektury i testowanie kontrolerów, zamiast implementacji zgodnie z MVC i umieszczeniem logiki w modelu, a nie w kontrolerach?

Dlaczego zepsucie? nie możesz mieć zgodnie z MVC oraz mieć możliwości testowania całego flow?

WeiXiao napisał(a):

Dlaczego zepsucie? nie możesz mieć zgodnie z MVC oraz mieć możliwości testowania całego flow?

Mogę, tylko po co sobie tak życie utrudniać?

Jeśli w kontrolerach nie ma żadnej logiki, to nie ma tam czego testować jednostkowo, więc nie ma sensu pisać takich testów (które wymagają więcej zachodu, bo trzeba mockować HttpContext i inne pierdoły.).
Cała logika jest w Modelu, który nie ma żadnych infrastrukturalnych zależności i banalnie się go testuje jednostkowo, bo nie trzeba mockować dziwnych rzeczy.

Cała logika jest w Modelu, który nie ma żadnych infrastrukturalnych zależności i banalnie się go testuje jednostkowo, bo nie trzeba mockować dziwnych rzeczy.

@WeiXiao

Dlatego argument bo ropzytorium mogę "mockować" w testach jest w większości pospolitych przypadkach delikatnie mówiąc bez sensu...

Albo testujesz domenę jednostokowo albo serwis nad domeną z repozytorium funkcyjnie-akceptacyjnie lub jak kto woli "integracyjnie"...