unit testy z bazą inmemory

0

W swoim projekcie mam klasy (serwisy), który odpowiadają za całą logikę biznesową. W każdej takiej klasie jedyną zależnością jest DbContext (nie używam wzorca repozytorium).
Chciałbym teraz napisać testy do tych serwisów. Jako, że nie mam repo, to cieżko zamockować DbContext, ale korzystam z EF CORE więc mogę odpalić to w trybie inmemory i nie mockować contextu.
Czy takie testy dalej można nazwać unit testami?

2

To jest śliska sprawa, bo ciężko to jednoznacznie zakwalifikować, różne źródła różnie definiują gdzie się kończą testy jednostkowe a gdzie się już zaczynają testy integracyjne.

  • Także widziałem już miejsca w których baza w pamięci była uznawana jako zaślepka i testy jako testy jednostkowe.
  • Widziałem też miejsca, w których baza zawsze jest traktowana jak coś nad czym nie mamy kontroli, a zatem testy były uznawane za integracyjne.
  • Widziałem też opinie które twierdziły że używanie bazy w pamięci w miejsce zwykłej bazy powoduje że testy się do niczego nie nadają, bo baza w pamięci zachowuje się inaczej niż zwykła baza.

Także wszystko zależy od kontekstu i własnej opinii.

0
Zimny Mleczarz napisał(a):

W swoim projekcie mam klasy (serwisy), który odpowiadają za całą logikę biznesową. W każdej takiej klasie jedyną zależnością jest DbContext (nie używam wzorca repozytorium).

To nie brzmi jak opis logiki biznesowej a raczej CRUDa.

Chciałbym teraz napisać testy do tych serwisów. Jako, że nie mam repo, to cieżko zamockować DbContext, ale korzystam z EF CORE więc mogę odpalić to w trybie inmemory i nie mockować contextu.
Czy takie testy dalej można nazwać unit testami?

Prędzej jednostkowymi niż integracyjnymi. Pytanie, czy w ogóle coś testują, bo jeśli nie, to problem znika. ;)
Mnie się wydaje, że takie hacki z puszczaniem testów na bazie w pamięci są dobre w jakichś legacy projektach, w których jest już kupa schrzanionej architektury, a testów nie było wcześniej. Ale nowy kod warto już projektować i pisać tak, aby takie cudowanie nie było potrzebne.

0

Właśnie sobie czytam książkę The Art of Unit Testing i natrafiłem na fragment o używaniu baz inmemory, także dla potomności co Roy Osherove o tym sądzi:

Some feel that another good option is to run the tests against an in-memory database.
My feelings on that are mixed. On the one hand, it’s closer to reality, in that you
also test the database logic. On the other hand, if your application uses a different
database engine, with different features, there’s a big chance that some things will
pass or fail during tests with the in-memory database and will work differently in production.
I choose to work with whatever is as close to the real thing as possible. Usually
that means using the same database engine.
If the in-memory database engine has the same features and logic embedded in it,
it might be a great idea.
0

Wow, nie wierzę, może następny świadomy będzie, który rozróżnia mock, stub i fake. Roy nie daje konkretnych wytycznych jeśli chodzi o testowanie jednostkowe a jednostkę określa jako jedną funkcjonalność, co akurat mi się nie podoba. Inaczej jest od strony Kent Beck i jego wersji bym się trzymał. Test z bazą najlepiej z takim samym schematem i silnikiem wykonuje tylko jeśli chcę przetestować rozszerzenia ORM lub cały "końcowy serwis". W innym przypadku prawdopodobnie testujesz funkcjonalność ORM, która została już przetestowana przez dostawcę albo masz zkopaną architekturę.

0
[Zimny Mleczarz napisał(a)]):

W swoim projekcie mam klasy (serwisy), który odpowiadają za całą logikę biznesową. W każdej takiej klasie jedyną zależnością jest DbContext (nie używam wzorca repozytorium).
Chciałbym teraz napisać testy do tych serwisów. Jako, że nie mam repo, to cieżko zamockować DbContext, ale korzystam z EF CORE więc mogę odpalić to w trybie inmemory i nie mockować contextu.
Czy takie testy dalej można nazwać unit testami?

A jaką logikę zawiera ten serwis oprócz operacji na ORM ?

1 użytkowników online, w tym zalogowanych: 0, gości: 1