Czy powinienem używać AutoMappera w swoich testach jednostkowych?

Question

Piszę testy jednostkowe dla metod kontrolera ASP.NET MVC.

Sterowniki te są zależne od IMapper - interfejsu utworzonego przeze mnie do abstrakcyjnej AutoMappera, przekazywanego za pośrednictwem wtrysku konstruktora za pomocą Castle Windsor.

Metody działania wykorzystują IMapper do mapowania obiektów z domen do obiektów ViewModel iz powrotem, mając na celu utrzymanie porządku w DRY i utrzymywanie zwięzłych metod działania.

W moich testów jednostkowych, mam

1. Konfiguracja AutoMapper z odpowiednimi wiązaniami (są one zbudowane przy użyciu profili AutoMapper, więc sprawdzalne i wielokrotnego użytku między projektami witryn oraz testów jednostka) i przekazać, że jako odpowiednia implementacja AutoMappera IMapper.

2. przepustkę atrapa obiektu (używam Min) dla instancji IMapper, w zależności od badania (oznaczałoby to powielenie popracować w kodzie konfiguracji testy, aby upewnić się obiekty wrócił z udawanym odwzorowującym odnoszą się do obiekty, których udawana mapka udaje mapę).

3. Ręcznie konfiguruj AutoMappera za pomocą mapowań, które według mnie będą potrzebne przy każdym teście (dużo pracy i oznacza, że ​​nie testuję odwzorowań, które naprawdę będą w użyciu).

Jaka jest opinia na temat korzystania z kodu infrastruktury w testach jednostkowych? W którym momencie staje się test integracyjny (tj. Testowanie integracji AutoMappera i kontrolerów)?

Wydaje się, że 2 jest purystycznym poglądem, chociaż myślę, że muszę dowiedzieć się więcej o Moq i jak uzyskać to, aby zwrócić wartości, które odnoszą się do rzeczywistych wartości przekazanych do metod, które kpią.

Answer 1

Mogłem mieć tendencję do zgadzania się z # 2. Wiesz, że automapper działa, znasz swoje prace wtryskowe (masz testy na to prawo? :-)) Skupiłbym się bardziej na szczegółach, rzeczach, które nie są tylko SomeClass.Property = AnotherClass.Property - TO SPECJALNE przypadki powinny być testowane nie podstawowe funkcje kopiowania. Nie testuj frameworka.

Jeśli chodzi o więcej kodu testowego - uważam, że jest całkowicie OK. Testy powinny być ustawione w ramach określonych testów (także w granicach rozsądku) dla danej jednostki.

Jeśli chodzi o Moq, składnia jest łatwa, nie należy jej nadużywać. var obj = new Mock(); następnie ustaw swoje właściwości, takie jak obj.Setup (x => x.Property) .returns ("hello"), chyba że masz bardziej szczegółowy problem? Moq ma również wszystkie ustawienia na nim, więc możesz nie potrzebować nawet automatappera, aby znaleźć go, to jest obj.SetupAllProperties();

Answer 2

jestem za nr 2 jak jeriley

dodanie do Min, jeśli trzeba zwrócić obiekt na podstawie wartości przekazanych do niej można napisać konfigurację tak:

mockObject.Setup(x => x.MapObject(It.IsAny()) 
      .Returns((ProductDto productDto) => 
      { 
       var product = new Product() 
       { 
        Id = productDto.Id, 
        Name = productDto.Name 
       }; 

       return product 
      });

Trochę brudny, ale poręczny.