Jeżeli testy jednostkowe obejmują wyłącznie oprogramowanie „funkcjonalne”

Używamy StructureMap w nowym projekcie rozwoju oprogramowania. Jeden z członków zespołu wdrożył test jednostkowy, który zasadniczo testuje konfigurację kontenera StructureMap . Robi to, wykonując następujące czynności;

• Liczy liczbę wystąpień zestawów skonfigurowanych dla klas w naszej przestrzeni nazw aplikacji.
• Definiuje oczekiwane wystąpienia na poziomie klasy
• Zapewnia, że ​​oczekiwane wystąpienia są zgodne z całkowitą liczbą znalezionych wystąpień.
• Zapewnia, że ​​oczekiwane wystąpienia są zgodne z tymi zdefiniowanymi w teście

Przykładem tego jest;

var repositories = container.GetAllInstances<IEnvironmentRepository>();
Assert.AreEqual(1, repositories .Count());
foundInstances = foundInstances + repositories .Count();

Mamy również „testy jednostkowe” dla następującej klasy;

public MyClass(IEnvironmentRepository environmentRepository)
        {

        }

W tych testach wyśmiewamy IEnvironmentRepository, więc nie wstrzykiwalibyśmy go z kontenera, jak to by się stało w systemie na żywo.

Kolega zignorował test jednostkowy w konfiguracji mapy struktury z komentarzem w stylu „Test jednostkowy testuje tylko własną konfigurację”. To był oczywiście cel testu i moim zdaniem jest całkowicie poprawny. Poprosiłem faceta, który zignorował test, o usunięcie konfiguracji mapy struktury dla IEnvironmentRepository(z testem wciąż ignorowanym) i uruchomienie pełnego zestawu testów jednostkowych, wszystkie przeszły pomyślnie. Następnie uruchomiliśmy aplikację, która się przewróciła, ponieważ konfiguracja kontenera była teraz nieprawidłowa. Moim zdaniem potwierdziło to wartość testu, mój kolega wciąż się nie zgadzał. Po prostu stwierdził, że nie powinniśmy testować konfiguracji, ale uważam, że mieści się to w zakresie testów jednostkowych.

Tak więc szereg pytań;

• Czy to prawidłowy test jednostkowy - Testujemy konfigurację naszego kontenera, nie działa mapa struktury (ale widzę nakładanie się)
• Jeśli nie, w jaki sposób można sprawdzić poprawność konfiguracji bez jej testowania. Jak powstrzymać kogoś przed przypadkowym usunięciem wymaganego wiersza kodu i wpisaniem go?
• Czy MyClasstest jednostkowy powinien rozwiązać instancję IEnvironmentRepositoryz kontenera i przekazać ją?

Jest to doskonale ważny automatyczny test. Nazywam je „testami architektury”, ponieważ weryfikują one poprawność szkieletowych elementów bazy kodu.

Czy kontener IoC jest w stanie rozpoznać i skomponować wszystkie drzewa obiektów w aplikacji? Czy auto Mapper może bezbłędnie mapować wszystkie zarejestrowane obiekty? Czy środkowa warstwa w Architekturze Cebuli nie odwołuje się do niczego zewnętrznego?

Testy te mogą zaoszczędzić dużo czasu, gdy pojawia się błąd konfiguracji, wskazując dokładnego winowajcę. Dobre frameworki dostarczają bardzo precyzyjnych komunikatów o błędach dotyczących tego, co jest nie tak, i otrzymujesz je, gdy tylko uruchomisz testy (najlepiej w sposób ciągły), a nie zakopujesz głęboko ślad stosu wykonawczego, jeśli masz szczęście.

Niezależnie od tego, czy są to testy jednostkowe ... prawdopodobnie nie, ale nadal działają w większości w pamięci i działają dość szybko. Z drugiej strony, nie wiem, to nie jest tak, że istniała powszechnie akceptowana definicja testu jednostkowego.

Problem z takim testem, który testuje wewnętrzne elementy programu, a nie jego wymaganie. Czy test może się nie powieść, nawet jeśli program działa zgodnie z wymaganiami.

W twoim przypadku, za każdym razem, gdy zmieniasz konfigurację kontenera, być może masz nową zależność, która wymaga wstrzyknięcia, przerywasz test.

Dodatkowo, jeśli dodasz dodatkowy wymóg zależności, ale zapomnij dodać go do kontenera i zmienić test kontenera. wszystko minie, ale twój program się zawiesi.

Lepszym automatycznym testem byłoby uruchomienie programu i sprawdzenie, czy ulega awarii.

Tego typu błędy należy wychwycić podczas testów integracji lub interfejsu użytkownika, nawet jeśli przejdą one testy jednostkowe.

To powiedziawszy, rosnąca złożoność konfiguracji kontenera jest uciążliwa. Być może niektóre „złe” testy są tego warte.

Kod testu jednostkowego. Wszystko poza tym to „inne” automatyczne testy - nazwij to jak chcesz. Wygląda na to, że testujesz tutaj konfigurację. Jeśli konfiguracja może ulec zmianie w zależności od środowiska, nie należy do testu jednostkowego. Rozważ dodanie atrybutu testu, aby wskazać, że test jest innego typu niż inne testy.

Pojemnik do wstrzykiwania zależności jest odpowiedzialny za przyklejenie różnych modułów w jednej działającej aplikacji .

Jeśli piszesz automatyczne testy dla swojej aplikacji - powinieneś mieć niewiele testów integracyjnych (lub akceptacyjnych), które wykonują testy „od końca do końca”, które przetestują cały potok aplikacji, że wszystkie moduły związane z konkretnym przypadkiem testowym są ze sobą sklejone poprawnie .

Te testy integracji zakończą się niepowodzeniem, jeśli kontener wstrzykiwania zależności nie zostanie poprawnie skonfigurowany. Co sprawia, że ​​testy jednostkowe dla samego kontenera są bezużyteczne, ponieważ test integracyjny powinien pokazać możliwe błędy w konfiguracji kontenera.

Nie musisz uwzględniać wszystkich możliwych przypadków testowych w testach integracyjnych, tylko jeden przypadek testowy na funkcję, który obejmuje całą drogę od interfejsu użytkownika do bazy danych.

Jeśli przypadki testowe integracji nie obejmują tworzenia określonej zależności, wystarczy ją dodać.

Dzięki testom integracyjnym możesz dowolnie zmieniać kontenery bez przepisywania testów jednostkowych w celu ich konfiguracji.

IMO, odpowiedzi są następujące:

1. Czy to prawidłowy test jednostkowy - Testujemy konfigurację naszego kontenera, nie działa mapa struktury (ale widzę nakładanie się)

   • Jest to poprawny test jednostkowy dla mapy struktury , nie dla twojego projektu, ponieważ test jednostkowy testuje określony kod, kpiąc ze wszystkich zależności, jeśli to konieczne, w celu przetestowania zaimplementowanej logiki. Logika konfiguracji jest zaimplementowana wewnątrz mapy struktury, dlatego ta biblioteka musi być dobrze przetestowana i musi zawierać testy jednostkowe, takie jak ta, o której wspomniałeś, i jeszcze więcej: powinna zawierać setki takich testów, dynamicznie wyśmiewać kilka konfiguracji w czasie wykonywania i testować, aby sprawdzić, czy pojemnik zachowuje się tak, jak powinien.

2. Jeśli nie, w jaki sposób można sprawdzić poprawność konfiguracji bez jej testowania. Jak powstrzymać kogoś przed przypadkowym usunięciem wymaganego wiersza kodu i wpisaniem go?

   • Możesz przetestować konfigurację ręcznie w wymaganym środowisku, a także możesz utworzyć automatyzację dla tego (test automatyczny), który testuje konkretną konfigurację, której potrzebujesz (nie musisz wyśmiewać rzeczy w czasie wykonywania).

3. Czy test jednostkowy MyClass powinien rozwiązać instancję IEnvironmentRepository z kontenera i przekazać ją do?

   • Nie, jest to idealny test jednostkowy, ponieważ wyśmiewasz zależność i testujesz logikę MyClass w izolowany sposób.

UnitTest weryfikuje pożądane zachowanie jednostki w separacji .

Oznacza to, że każdy rodzaj konfiguracji jest nie w zakresie UnitTests .

Niemniej jednak powinieneś mieć zautomatyzowane testy dla swoich konfiguracji, ale to nie są testy UnitTest ...