Czy przydatne są metody testów jednostkowych, w których jedyną logiką są osłony?

Powiedz, że mam taką metodę:

public void OrderNewWidget(Widget widget)
{
   if ((widget.PartNumber > 0) && (widget.PartAvailable))
   {
        WigdetOrderingService.OrderNewWidgetAsync(widget.PartNumber);
   }
}

Mam kilka takich metod w moim kodzie (przednia połowa asynchronicznego wywołania usługi sieci Web).

Zastanawiam się, czy warto ich objąć testami jednostkowymi. Tak, tutaj jest logika, ale to tylko logika wartownicza. (Czyli upewniam się, że mam potrzebne rzeczy, zanim pozwolę na wywołanie usługi internetowej).

Część mnie mówi „pewnie, że możesz je przetestować w jednostce, ale nie jest to warte czasu” (jestem przy projekcie, który jest już opóźniony).

Ale druga strona mnie mówi, że jeśli ich nie przetestujesz, a ktoś zmieni Strażników, mogą wystąpić problemy.

Ale pierwsza część mnie mówi: jeśli ktoś zmieni strażników, to po prostu wykonujesz dla nich więcej pracy (ponieważ teraz oni muszą zmienić strażników i testy jednostkowe dla strażników).

Na przykład, jeśli moja usługa przyjmuje na siebie odpowiedzialność za sprawdzenie dostępności Widżetu, być może nie chcę już tego strażnika. Jeśli jest to test jednostkowy, muszę teraz zmienić dwa miejsca.

Widzę zalety i wady na dwa sposoby. Pomyślałem więc, że zapytam, co zrobili inni.

Część mnie mówi „pewnie, że możesz je przetestować w jednostce, ale nie jest to warte czasu” (jestem przy projekcie, który jest już opóźniony).

To trzy bardzo krótkie testy. Spędziłeś tyle czasu, zadając sobie pytanie.

Ale druga strona mnie mówi, że jeśli ich nie przetestujesz, a ktoś zmieni Strażników, mogą wystąpić problemy.

Posłuchaj tej strony.

Ale pierwsza część mnie mówi: jeśli ktoś zmieni strażników, to po prostu wykonujesz dla nich więcej pracy (ponieważ teraz oni muszą zmienić strażników i testy jednostkowe dla strażników).

Jeśli twoim opiekunem jest orzech TDD, utrudniasz im to. Każda zmiana, którą dokonuję bez powiązanej zmiany lub dodania testów, powoduje, że muszę intensywnie myśleć. W rzeczywistości prawdopodobnie dodałbym testy, zanim zacznę wprowadzać zmiany.

Pierwsza część ciebie jest po prostu błędna. Poklep drugą część plecami i przestań o tym myśleć.

Uprościłoby to testowanie jednostkowe, gdyby logika ochronna i faktyczne zamawianie były odrębnymi metodami.

W Widgetklasie

public bool IsReadyForOrdering { get { return PartNumber > 0 && PartAvailable; } }

lub równoważna metoda gdzie indziej

public bool IsWidgetReadyForOrdering(Widget widget)
{
    return widget.PartNumber > 0 && widget.PartAvailable;
}

Metoda zamówienia

public void OrderNewWidget(Widget widget)
{
   if (IsWidgetReadyForOrdering(widget)) {
        WigdetOrderingService.OrderNewWidgetAsync(widget.PartNumber);
   }
}

Teraz testowanie IsWidgetReadyForOrderingstało się łatwe. Nie myśl o tym dłużej. Sprawdź to!

Jeśli nie masz czasu w harmonogramie testów jednostkowych, ale masz czas przeznaczony na solidne korzystanie z QA, zapytaj, czy możesz ukraść część tego czasu na napisanie testów jednostkowych, czy też możesz poświęcić część okresu QA robienie testów jednostkowych, a może po prostu radzenie sobie z kodem, który nie jest testowany jednostkowo. Niestety harmonogramy, które są nieruchome, zmuszają cię do ustępstw lub pracy na śmierć, generalnie sugeruję pierwszą opcję, ponieważ druga spowoduje, że nie będziesz w stanie wspierać / utrzymanie systemu poprawnie przez cały okres jego ważności.

To powiedziawszy, na twoje ogólne pytanie dotyczące testowania wypowiedzi strażników; Tak! Absolutnie przetestuj strażników! Są to ważne elementy zachowania tej metody, nie będzie chciał się dowiedzieć, że ktoś coś robi źle zrozumiany bug-fix i usunięto swoich strażników lub zmienił &&się ||prawda? Testy jednostkowe upewnią się, że a) rzeczywiście masz logikę na swoich strażnikach i b) nikt później nie złamie tej logiki, nie otrzymując skargi, gdy przeprowadzą testy jednostkowe, mówiąc im, że z jakiegoś powodu tak powinno być.

Powyżej znajduje się kilka doskonałych odpowiedzi, a ich uwagi są bardzo ważne. Ale wydaje się, że pominięto to, że masz kompleksowy zestaw testów jednostkowych, które czytają jak bardzo szczegółową specyfikację kodu. Jeśli pominiesz sprawdzanie poprawności tylko dlatego, że kod jest tak łatwy, że trudno zrozumieć, jak może się nie udać, brakuje części specyfikacji. Gdybym wszedł do zespołu, w którym te testy zostały pominięte, zakładałbym, że twoja usługa nie potwierdziła swoich argumentów.

Kod to kod. Powinieneś spróbować uzyskać 100% zasięgu podczas testowania. Gdyby to nie było ważne, nie byłoby go.