Czy pierwiastek kompozycji wymaga testów jednostkowych?

Question

Próbowałem znaleźć odpowiedź, ale wygląda na to, że nie jest to bezpośrednio dyskutowane. Mam główny składnik mojej aplikacji, w którym utworzę kontener DI i zarejestruję wszystko tam, a następnie rozwiązam potrzebne klasy najwyższego poziomu, które pobierają wszystkie zależności. Wszystko dzieje się wewnętrznie - ciężko jest jednostce przetestować główny składnik kompozycji. Możesz robić wirtualne metody, chronione pola itd., Ale nie jestem wielkim fanem wprowadzania takich rzeczy tylko po to, aby móc testować jednostki. Nie ma większych problemów z innymi klasami, ponieważ wszystkie używają wtrysku konstruktora. Pytanie brzmi - czy ma sens testowanie korzeni kompozycji? Ma dodatkową logikę, ale niewiele, a w większości przypadków pojawiały się błędy podczas uruchamiania aplikacji. Niektóre kod, który mam:

public void Initialize(/*Some configuration parameters here*/) 
    { 
     m_Container = new UnityContainer(); 

     /*Regestering dependencies*/ 

     m_Distributor = m_Container.Resolve<ISimpleFeedMessageDistributor>(); 
    } 

    public void Start() 
    { 
     if (m_Distributor == null) 
     { 
      throw new ApplicationException("Initialize should be called before start"); 
     } 

     m_Distributor.Start(); 
    } 

    public void Close() 
    { 
     if (m_Distributor != null) 
     { 
      m_Distributor.Close(); 
     } 
    } 

Answer 1

to większego sensu, aby przetestować korzeń kompozycji w ogóle?

Chcesz się dowiedzieć, czy Twój wniosek został napisany poprawnie? Prawdopodobnie to robisz i dlatego piszesz testy. Z tego samego powodu powinieneś przetestować korzeń kompozycji.

Testy te są jednak ukierunkowane na poprawność okablowania systemu. Nie chcesz sprawdzać, czy pojedyncza klasa działa poprawnie, ponieważ jest już objęta pewnym testem jednostkowym. Nie chcesz też sprawdzać, czy klasy wywołują inne klasy we właściwej kolejności, ponieważ to właśnie chcesz przetestować w swoich normalnych testach integracyjnych (zadzwoń do kontrolera MVC i sprawdź, czy połączenie kończy się w bazie danych jest przykładem takiego testu integracji).

Oto kilka rzeczy, które prawdopodobnie powinny Test:

• , że wszystkie klasy najwyższego poziomu może zostać rozwiązany. Zapobiega to konieczności klikania wszystkich ekranów w aplikacji, aby sprawdzić, czy wszystko jest poprawnie podłączone.
• Składniki te zależą tylko od usług świadczonych na równi lub dłużej. Gdy komponenty zależą od innego komponentu, który ma krótszy czas życia, składnik ten "będzie promować" czas życia tej zależności, co często prowadzi do błędów, które są trudne do odtworzenia i naprawienia. Sprawdzanie tego rodzaju problemów jest ważne. Ten typ błędu jest również znany jako niedopasowanie stylu życia lub zależność od użytkownika.
• To dekoratory i inne mechanizmy przechwytywania, które są kluczowe dla poprawności aplikacji, są stosowane prawidłowo. Dekoratorzy mogą na przykład dodać zagadnienia przekrojowe, takie jak obsługa transakcji, bezpieczeństwo i buforowanie, a ważne jest, aby obawy te były wykonywane we właściwej kolejności (na przykład sprawdzenie bezpieczeństwa musi być wykonane przed wysłaniem zapytania do pamięci podręcznej), ale może być trudno przetestuj to, używając normalnego testu integracji.

Aby móc to zrobić, musisz jednak mieć verifiable DI configuration.

Należy zauważyć, że not everybody dzieli się tą opinią. Z mojego doświadczenia wynika jednak, że weryfikacja poprawności konfiguracji jest bardzo cenna.

Testowanie tych rzeczy może być trudne w przypadku niektórych kontenerów IoC, podczas gdy inne pojemniki IoC mają ułatwienia w tym zakresie (ale Unity niestety nie ma większości tych funkcji).

Niektóre pojemniki mają nawet pewną metodę weryfikacji, którą można wywołać, która zweryfikuje konfigurację. Co oznacza "weryfikacja" w przypadku każdej biblioteki różni się.Simple Injector na przykład (jestem głównym programistą Simple Injector) ma metodę Verify, która po prostu wykonuje iterację wszystkich rejestracji i wywołuje na każdym z nich GetInstance, aby zapewnić, że każde wystąpienie może zostać utworzone. Zawsze radzę użytkownikom, których nazwiesz Verify w swoim katalogu głównym kompozycji, gdy tylko jest to możliwe. Nie zawsze jest to możliwe, na przykład, gdy konfiguracja staje się duża, wywołanie polecenia Verify może spowodować, że aplikacja uruchomi się zbyt wolno. Ale nadal jest to dobry punkt wyjścia i może usunąć wiele bólu. Jeśli zajmie to dużo czasu, zawsze możesz przenieść połączenie do automatycznego testu.

I dla Simple Injector, to dopiero początek. Simple Injector zawiera Diagnostic Services, który sprawdza kontener w przypadku typowych błędnych konfiguracji, takich jak wcześniej określone "niedopasowanie stylu życia".

Tak więc koniecznie powinieneś przetestować, ale nie jestem pewien, czy wywołać te testy "testami jednostkowymi", chociaż udaje mi się uruchomić te testy w izolacji (bez konieczności uderzania w bazę danych lub usługę internetową).