Jednostka testująca wiele warunków w instrukcji IF

Mam fragment kodu, który wygląda mniej więcej tak:

function bool PassesBusinessRules()
{
    bool meetsBusinessRules = false;

    if (PassesBusinessRule1 
         && PassesBusinessRule2
         && PassesBusinessRule3)
    {
         meetsBusinessRules= true;
    }

    return meetsBusinessRules;
}

Uważam, że dla tej konkretnej funkcji powinny być cztery testy jednostkowe. Trzy, aby przetestować każdy z warunków w instrukcji if i upewnić się, że zwraca false. I kolejny test, który upewnia się, że funkcja zwraca true.

Pytanie: Czy zamiast tego powinno być dziesięć testów jednostkowych? Dziewięć, które sprawdza każdą z możliwych ścieżek awarii. TO ZNACZY:

• Fałsz Fałsz Fałsz
• Fałsz Fałsz Prawda
• Fałsz Prawda Fałsz

I tak dalej dla każdej możliwej kombinacji.

Myślę, że to przesada, ale niektórzy inni członkowie mojego zespołu nie. Patrzę na to, jeśli BusinessRule1 zawiedzie, to zawsze powinien zwracać false, nie ma znaczenia, czy został sprawdzony pierwszy czy ostatni.

Formalnie te rodzaje pokrycia mają nazwy.

Po pierwsze, istnieje predykat : chcesz mieć przypadek testowy, który sprawi, że instrukcja if będzie prawdziwa, i taki, który sprawi, że będzie fałszywy. Spełnienie tego pokrycia jest prawdopodobnie podstawowym wymogiem dla dobrego zestawu testów.

Potem jest Pokrycie Warunków : Tutaj chcesz sprawdzić, czy każdy warunek podrzędny w if ma wartość true i false. To oczywiście tworzy więcej testów, ale zwykle wykrywa więcej błędów, więc często dobrym pomysłem jest dołączenie do zestawu testów, jeśli masz czas.

Najbardziej zaawansowane kryteria pokrycia nazywane są zwykle kombinatorycznym pokryciem warunków : tutaj celem jest stworzenie przypadku testowego, który przejdzie wszystkie możliwe kombinacje wartości logicznych w teście.

Czy jest to lepsze niż proste orzeczenie lub pokrycie warunków? Oczywiście pod względem zasięgu. Ale to nie jest darmowe. Jest to bardzo kosztowne w utrzymaniu testów. Z tego powodu większość ludzi nie zawraca sobie głowy pełnym zasięgiem kombinatorycznym. Zwykle testowanie wszystkich gałęzi (lub wszystkich warunków) będzie wystarczające do wyłapywania błędów. Dodanie dodatkowych testów do testowania kombinatorycznego zwykle nie wykrywa większej liczby błędów, ale wymaga dużo wysiłku, aby je stworzyć i utrzymać. Dodatkowy wysiłek zwykle sprawia, że ​​nie jest to warte bardzo małej wypłaty, więc nie poleciłbym tego.

Część tej decyzji powinna opierać się na ryzykownym podejściu do tego kodu. Jeśli ma dużo miejsca na awarię, warto ją przetestować. Jeśli jest nieco stabilny i niewiele się zmieni, powinieneś rozważyć skoncentrowanie wysiłków na testowaniu gdzie indziej.

Ostatecznie zależy to od Ciebie (zespołu), kodu i konkretnego środowiska projektu. Nie ma uniwersalnej zasady. Zespół (r) powinien napisać tyle testów, ile potrzeba, aby upewnić się, że kod jest rzeczywiście poprawny . Więc jeśli twoi koledzy z drużyny nie przekonają 4 testów, być może potrzebujesz więcej.

Czas OTOH na napisanie testów jednostkowych jest zwykle rzadkim zasobem. Staraj się więc znaleźć najlepszy sposób na spędzenie ograniczonego czasu . Na przykład, jeśli masz inną ważną metodę z pokryciem 0%, może być lepiej napisać kilka testów jednostkowych, aby ją objąć, niż dodać dodatkowe testy dla tej metody. Oczywiście zależy to również od tego, jak delikatne jest wdrożenie każdego z nich. Planowanie wielu zmian tej konkretnej metody w dającej się przewidzieć przyszłości może uzasadniać dodatkowe pokrycie testem jednostkowym. Może być na krytycznej ścieżce w programie. Są to wszystkie czynniki, które tylko ty (zespół) możesz ocenić.

Osobiście zazwyczaj byłbym zadowolony z 4 testów, które nakreśliłeś, to znaczy:

• prawda fałsz fałsz
• fałsz prawda fałsz
• fałsz fałszywy prawda
• prawda prawda prawda

plus może jeden:

• prawda prawda prawda fałsz

aby upewnić się, że jedynym sposobem na uzyskanie wartości zwrotu truejest spełnienie wszystkich 3 reguł biznesowych. Ale ostatecznie, jeśli twoi koledzy z drużyny nalegają na uwzględnienie ścieżek kombinatorycznych, dodanie tych dodatkowych testów może być tańsze niż kontynuowanie sporu o wiele dłużej :-)

Jeśli chcesz być bezpieczny, potrzebujesz ośmiu testów jednostkowych przy użyciu warunków reprezentowanych przez trzy zmienne tabele prawdy ( http://teach.valdosta.edu/plmoch/MATH4161/Spring%202004/and_or_if_files/image006.gif ).

Nigdy nie możesz być pewien, że logika biznesowa zawsze określa, że ​​kontrole są przeprowadzane w tej kolejności i chcesz, aby test wiedział jak najmniej o rzeczywistej implementacji.

Tak, powinna istnieć pełna kombinacja w idealnym świecie.

Podczas wykonywania testu jednostkowego naprawdę powinieneś spróbować zignorować sposób działania metody. Wystarczy podać 3 dane wejściowe i sprawdzić, czy dane wyjściowe są prawidłowe.

Państwo jest złe. Poniższa funkcja nie wymaga testu jednostkowego, ponieważ nie ma skutków ubocznych i jest dobrze zrozumiane, co robi, a czego nie. Po co to testować? Nie ufasz własnemu mózgowi ??? Funkcje statyczne są świetne!

static function bool Foo(bool a, bool b, bool c)
{
    return a && b && c;
}

Wiem, że to pytanie jest dość stare. Ale chcę nadać temu zagadnieniu inną perspektywę.

Po pierwsze, testy jednostkowe powinny mieć dwa cele:

1. Twórz dokumentację dla siebie i swoich kolegów z zespołu, aby po upływie określonego czasu zapoznać się z testem jednostkowym i upewnić się, że rozumiesz what's the class' intentionihow the class is doing its work
2. Podczas opracowywania test jednostkowy upewnia się, że kod, który piszemy, działa zgodnie z przeznaczeniem.

Podsumowując problem, chcemy przetestować complex if statement, dla podanego przykładu istnieją 2 ^ 3 możliwości, czyli ważną liczbę testów, które możemy napisać.

• Możesz dostosować się do tego faktu i zapisać 8 testów lub skorzystać z testów sparametryzowanych
• Możesz również postępować zgodnie z innymi odpowiedziami i pamiętać, że testy powinny być jasne z zamiarem, w ten sposób nie będziemy bałagać się zbyt wieloma szczegółami, które w najbliższej przyszłości mogą być trudniejsze do zrozumienia what is doing the code

Z drugiej strony, jeśli jesteś w stanie, że twoje testy są jeszcze bardziej złożone niż implementacja, to dlatego, że implementacja powinna zostać przeprojektowana (mniej więcej w zależności od przypadku) niż sam test.

Na przykład w przypadku złożonych instrukcji if możesz zastanowić się nad wzorcem odpowiedzialności łańcucha , implementując każdy moduł obsługi w ten sposób:

If some simple business rule apply, derive to the next handler

Jak łatwo byłoby przetestować różne proste reguły zamiast złożonej reguły?

Mam nadzieję, że to pomoże,

Jest to jeden z tych przypadków, w których coś takiego jak Quickcheck ( http://en.wikipedia.org/wiki/QuickCheck ) będzie twoim przyjacielem. Zamiast ręcznie zapisywać wszystkie N przypadków, komputer powinien wygenerować wszystkie (lub przynajmniej dużą liczbę) możliwych przypadków testowych i sprawdzić, czy wszystkie zwracają sensowny wynik.

Programujemy komputery do życia tutaj, dlaczego nie zaprogramować komputera do generowania dla ciebie przypadków testowych?

Możesz zmienić warunki na warunki ochrony:

if (! PassesBusinessRule1) {
    return false;
}

if (! PassesBusinessRule2) {
    return false;
}

if (! PassesBusinessRule3) {
    return false;
}

Nie sądzę, żeby to zmniejszyło liczbę przypadków, ale z mojego doświadczenia wynika, że ​​łatwiej jest je rozdzielić w ten sposób.

(Zauważ, że jestem wielkim fanem „pojedynczego punktu wyjścia”, ale robię wyjątek dla warunków ochronnych. Są jednak inne sposoby strukturyzacji kodu, abyś nie miał osobnych zwrotów.)