[GaHee]

Cześć #dotnet corowe świry, czy macie pomysł jak zmokować Automappera w unit testach (xunit)? Czy jest jakaś możliwość, żebym przekazał go przez DI z projektu, który zawiera web api?

#programowanie #unittest #naukaprogramowania #csharp

[Niebieskowaty]

@GaHee: Mapper.Initialize(m => m.AddProfile());
Mapper.AssertConfigurationIsValid();

[M.....n]

@GaHee: Nie mockujesz automapera tylko tak jak @Niebieskowaty napisał wstawiasz inny profil z mapowaniami

[GaHee]

@Niebieskowaty: @Myrten: Czegoś chyba nie rozumiem. Załóżmy, że mam klasę, które ma w konstrutorze IMapper mapper, jak za pomocą tego co napisał @Niebieskowaty przekazać IMapper do konstruktora. Dzięki za pomocą i wesołych świąt. Żeby każdy dzień był zielony w test explorerze. :D

[M.....n]

@GaHee: Nie wstrzykujesz mappera do konstruktorów tylko traktujesz go jak statycznego singletona którego inicjalizujesz przed odpaleniem testów/aplikacji

[GaHee]

@Myrten: Kurde, wszędzie gdzie nie spojrzę, wszyscy wykorzystują dobrodziejstwo built-in DI .AddAutoMapper() i wstrzykują przez konstruktor. Masz może jakiś fragment kodu z singletonem?

[Niebieskowaty]

@GaHee: no możesz zmockować mappera, żeby zwracał zawsze to samo po wywołaniu jakiejś tam metody używając Moq czy innego frameworka do mocków. Ale czy to ma sens? Wydaje mi się, że lepiej będzie napisać test który sprawdza mappingi, a jak testujesz klasę która potrzebuje mappera to jej go daj

[GaHee]

@Niebieskowaty:
Przyjmijmy, że chce przetestować taką metodę:

public async Task> GetBooksForUserAsync(string userId, int pageSize, int pageNumber)
 {
 var user = await _context.Users.Include(u => u.Books).FirstOrDefaultAsync(u

[M.....n]

@GaHee: Jak twój kontener DI ma .AddAutoMapper() to sprawdź czy tam nie ma jakiś przeciążeń albo innych opcji pozwalających podać profil automapera i wtedy przy testach podmieniasz ten profil

[Niebieskowaty]

@GaHee: @Myrten: pytanie, czy te testy będą jednostkowe czy już integracyjne? Jak chcesz "zmockować" _context w podanym przykładzie?

[GaHee]

@Niebieskowaty: Jednostkowe, za pomocą SqliteInMemoryDb. https://github.com/JonPSmith/EfCore.TestSupport/wiki

Póki co, mam coś takiego: https://pastebin.com/vn7yN1tc

[Niebieskowaty]

@GaHee: no widzisz, czyli bazy danych też nie mockujesz jako tako tylko tworzysz specjalną wersję na testy. Z mapperem jest to samo, jeśli chciałbyś go zmockować to musiałbyś stworzyć mocki dla metod Map które zwrócą Ci określony obiekt, to droga do nikąd według mnie.

https://stackoverflow.com/a/43875874

Tutaj nawet człowiek z teamu automappera nie widzi sensu żeby go mockować :P W przygotowywaniu testu zrób kawałek kodu z tej dokumentacji http://docs.automapper.org/en/stable/Configuration.html

Oczywiście możesz

[Niebieskowaty]

Póki co, mam coś takiego: https://pastebin.com/vn7yN1tc

@GaHee: no to zamiast tworzyć mock po prostu skonfiguruj tego mappera i go przekaż. :)

[GaHee]

@Niebieskowaty: @Myrten: Dzięki za pomoc. @Niebieskowaty skorzystałem z twojej sugestii i sprawdziła się w stu procentach. Jeszcze muszę popracować nad tymi testami.

[Niebieskowaty]

@GaHee pamietaj, ze kazdy framework ma atrybuty do metod ktore moga sie wykonywać przed każdym testem albo przed kazdym testfixture. Dzieki temu kod który będzie Ci sie powtarzal w każdym tescie możesz tam umieścić

[GaHee]

@Niebieskowaty: Właśnie myślę o tym, żeby wydzielić, gdzieś ten kod odpowiedzialny za tworzenie InMemoryDb etc. Też nie do końca mi do gustu przypadł ten xUnit, chyba przyjemniejszy w odbiorze był nUnit.

[Niebieskowaty]

@GaHee no ja w pracy używałem tylko nUnita więc nie mam zdania co do innych. A co do kodu to jest dużo możliwości żeby to ładnie uporządkować. W NUnicie sa SetUp i TearDown atrybuty chyba, masz jeszcze konstruktor klasy z testami który też może coś zrobić ;)

[M.....n]

@GaHee: Też uważam że nUnit jest lepszy ( ͡° ͜ʖ ͡°)