Przygotowywanie bazy w testach integracyjnych

Widzę dwie możliwości przygotowywania bazy danych w testach integracyjnych:

1. utworzenie jakiegoś globalnego seedera i odpalenie go w jakimś TestsBase (tak jak to robią w tutorialach)
2. przygotowywanie bazy dla każdego testu osobno, np. tutaj wysłanie komendy RegisterCustomer przed wysłaniem PlaceCustomerOrder (co prawda jakaś wstępna baza tam jednak jest, ale rozumiecie ideę). U mnie wyglądałaby to tak, że wykonuję kilka żądań do API na początku każdego testu.

I nie wiem, co kiedy kiedy wybrać. :/

No w przypadku tworzenia typowego API/aplikacji wybrałbym raczej 2 opcję. Dane wstawiane przez seeder zamiast przez API mogą być niekompatybilne z tym, co API wstawia, więc możesz mieć false negativy, albo co gorsza false positivy.

Ja zawsze stosowałem to drugie rozwiązanie. Test zakładał praktycznie wszystkie dane i jak się zwijał to jo usuwał.

Why not both?

Każdy test dostaje nową instancje bazy sqlite bo jest lekka i prawdziwa

Niektóre rzeczy są seedowane z góry np. user_permissions

Niektóre rzeczy są dodawane ręcznie, bo ich tworzenie jest otestowane w innym miejscu, a tutaj testuje coś innego, ale zależnego. np. test User może utworzyć X, więc Usera wrzucam ręcznie do sqlite i testuje proces tworzenia X, bo po co mam znów Register testować?

Na koniec testu leci drop instancji sqlite.

WeiXiao napisał(a):

Każdy test dostaje nową instancje bazy sqlite bo jest lekka i prawdziwa

Taa, zwłaszcza ze swoimi trzema typami danych jest taka prawdziwa.

@somekind:

Jeżeli masz jakieś bardziej wymagające przypadki to w tych testach możesz akurat użyć InMemory ;)

@somekind pewnie by chciał coś takiego: https://nance.io/leveling-up-your-dotnet-testing-transactional-integration-testing-in-asp-net-core/ :)