Jednostka wtrysku testowanie konstruktor

Question

Załóżmy, że mój Foo klasa ma następujące elementy:

readonly IService service; 

public Foo(IService service) 
{ 
    if (service == null) 
     throw new ArgumentNullException("service"); 

    this.service = service; 
} 

public void Start() 
{ 
    service.DoStuff(); 
} 

tej pory, mam jeden test jednostki dla konstruktora, gdzie przechodzą w wartość null w celu sprawdzenia, że ​​ArgumentNullException zostaje wrzucony. Czy potrzebuję drugiego testu jednostkowego dla mojego konstruktora, w którym przekazuję ważny IService i sprawdzam, czy ustawiono this.service (co wymagałoby publicznego dostępu)?

Czy powinienem po prostu polegać na mojej jednostce testowej dla metody Start, aby przetestować tę ścieżkę kodu?

Answer 1

Ustawienie this.service jest szczegółem implementacji, więc powinieneś po prostu testować, że jest używany tam, gdzie jest to oczekiwane i po prostu przetestuj to za pomocą metody Start. Aby twoje testy nie stały się kruche.

Użytkownik chce jedynie sprawdzić, czy usługa jest używana prawidłowo. Nie powinieneś się przejmować, w jaki sposób jest przechowywany.

Answer 2

Te testy są zbędne, ponieważ żaden inny test nie powiedzie się, gdy twój konstruktor nie zadziała.

Szczerze mówiąc, nawet nie próbuję pisać tych sprawdzeń zerowych w moich konstruktorach. Powód jest prosty: kontenery DI nie pozwalają na automatyczne podawanie konstruktorów z zerowymi odwołaniami (lub przynajmniej nie domyślnie), więc nie ma możliwości konstruowania typów przy użyciu wartości pustych (gdy są automatycznie podłączone przez kontener) . Więc dodaje tylko bezużyteczny kod, który sprawia, że ​​dodajemy niepotrzebne testy, gdy chcę mieć wysoki zasięg kodu.

Mówię, że pomijam te puste kontrole i ufam Twojemu kontenerowi DI (lub wybieram kontener DI, któremu możesz zaufać).