unit testy z bazą inmemory

Odpowiedz Nowy wątek
2018-05-20 19:46
Zimny Mleczarz
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?

Pozostało 580 znaków

2018-05-21 09:10
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.


#Dżunior React Devloper wanna be#
Generalnie tak. Jak masz pełną kontrolę nad bazą, jej schematem i dostępem do niej, to taka baza nie różni sìę mentalnie od tego, gdyby była tam lista, mapa. Wiec unit test. Bazy in mem to wyjscie pragmatyczne, przeważnie da sie skutecznie tedtować, ale tu wiele zależy od projektu, 'ormów'. - jarekr000000 2018-05-23 07:06

Pozostało 580 znaków

2018-05-23 04:01
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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2018-05-23 15:06
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.

#Dżunior React Devloper wanna be#
Jeśli dobrze zrozumiałem, nic nie stoi na przeszkodzie aby w ten sposób robić testy w tym przypadku? Bo EF Core in_memory będzie działał dokładnie jak prawdziwa baza danych. - szydlak 2018-05-23 15:18
Tak samo jak np Oracle albo Postgres? Tak samo wspiera procedury i widoki? - somekind 2018-05-23 22:51

Pozostało 580 znaków

2018-05-23 19:24
Krzywy Rycerz
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ę.

Pozostało 580 znaków

2018-05-23 19:30
Krzywy Rycerz
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 ?

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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