Czy testowanie jednostek powoduje, że Debug.Assert() jest niepotrzebny?

Question

Już od jakiegoś czasu przygotowałem "McDell'a" Code Complete ". Teraz przeczytałem go ponownie w Hunt & Thomasa "The Pragmatic Programmer": Użyj twierdzeń! Uwaga: Twierdzenia o braku testów jednostkowych, czyli Debug.Assert().

Po pytaniach SO When should I use Debug.Assert()? i When to use assertion over exceptions in domain classes twierdzenia są użyteczne dla rozwoju, ponieważ sytuacje "niemożliwe" można znaleźć dość szybko. I wydaje się, że są one powszechnie używane. O ile rozumiałem twierdzenia, w języku C# są często używane do sprawdzania zmiennych wejściowych dla "niemożliwych" wartości.

Aby testy jednostkowe były zwięzłe i izolowane w jak największym stopniu, robię klasy i metody dla feedu z danymi wejściowymi "niemoŜliwym" (jak pusty ciąg znaków).

Takie testy wyraźnie dokumentują, że nie polegają na określonych danych wejściowych. Uwaga: ćwiczę, co "wzorce testowe" Meszarosa "opisuję jako Minimal Fixture.

I o to właśnie chodzi: gdybym miał zapewnione osłony chroniące te dane, to wysadziłby moje testy jednostkowe.

Podoba mi się pomysł programowania asertywnego, ale z drugiej strony nie muszę go wymuszać. Obecnie nie mogę myśleć o jakimkolwiek użyciu dla Debug.Assert(). Może jest coś, za czym tęsknię? Czy masz jakieś sugestie, gdzie mogą być przydatne? Może po prostu przeceniam użyteczność twierdzeń? A może mój sposób testowania musi zostać ponownie przeanalizowany?

Edytuj: Best practice for debug Asserts during Unit testing jest bardzo podobny, ale nie odpowiada na pytanie, które mi przeszkadza: czy powinienem zadbać o Debug.Assert() w języku C#, czy testuję tak, jak to opisałem? Jeśli tak, to w jakiej sytuacji są one przydatne? Z mojego obecnego punktu widzenia takie testy jednostek sprawiają, że Debug.Assert() jest niepotrzebne.

Kolejny punkt: jeśli naprawdę tak uważasz, jest to duplikat pytania, po prostu dodaj komentarz.

Answer 1

Teoretycznie masz rację - wyczerpujące testy sprawiają, że zwolnienia są zbyteczne. W teorii. W parctice są nadal przydatne do debugowania twoich testów i do łapania prób przez przyszłych programistów, którzy mogą próbować używać interfejsów niezgodnie z ich zamierzoną semantyką.

Podsumowując, służą one wyłącznie do celów innych niż testy jednostkowe. Są po to, aby łapać błędy, które z natury rzeczy nie zostaną popełnione podczas pisania testów jednostkowych.

Zalecam ich przechowywanie, ponieważ oferują one kolejny poziom ochrony przed błędami programistów.

Są również lokalnymi mechanizmami ochrony przed błędami, podczas gdy testy jednostkowe są niezależne od testowanego kodu. Znacznie łatwiej jest "nieumyślnie" wyłączyć testy jednostkowe pod presją, niż wyłączyć wszystkie potwierdzenia i sprawdzenia w czasie wykonywania w kawałku kodu.

Answer 2

Jeśli przeprowadzasz wyczerpujące testy jednostkowe, które obejmują wszystkie przypadki, w których możesz napotkać dziwne, skrajne przypadki, to nie sądzę, abyś uznał twierdzenia za bardzo użyteczne. Większość osób, które nie testują twierdzeń o miejscu testowania, by ustalić podobne ograniczenia, które złapią podczas testów.

Answer 3

Używam zarówno testów jednostkowych, jak i zapewnień, do różnych celów.

Testy jednostkowe to zautomatyzowane eksperymenty pokazujące, że twój program (i jego części) działa zgodnie z określonymi. Podobnie jak w matematyce eksperymentowanie nie jest dowodem, o ile nie można wypróbować każdej możliwej kombinacji danych wejściowych. Nic nie demonstruje tego lepiej niż fakt, że nawet przy testach jednostkowych Twój kod będzie zawierał błędy. Niewiele, ale będzie je mieć.

Asercje służą do przechwytywania podejrzanych sytuacji w czasie wykonywania, które normalnie nie powinny się zdarzać. Być może słyszałeś o warunkach wstępnych, warunkach końcowych, niezmiennych pętlach i podobnych rzeczach. W realnym świecie nie często przechodzimy przez formalny proces faktycznego udowodnienia (logiką formalną), że fragment kodu dostarcza określonych warunków końcowych, jeśli warunki wstępne są spełnione. To byłby prawdziwy matematyczny dowód, ale często nie mamy czasu, aby to zrobić dla każdej metody. Jednak sprawdzając, czy warunki wstępne i warunki końcowe są spełnione, możemy zauważyć problemy na znacznie wcześniejszym etapie.

Answer 4

Myślę, że ideą Unit Testing w tym przypadku jest przeniesienie tych twierdzeń na przypadki testowe, aby upewnić się, że zamiast Debug.Assert (...) testowany kod obsługuje go bez rzucania (lub zapewnia poprawne wyrzucenie).

Answer 5

Generalnie widzę, że przyzwyczajenia są używane do sprawdzania poprawności stanu wewnętrznego, a nie do sprawdzania argumentów.

IMO wejścia do solidnego interfejsu API powinny być chronione przez kontrole, które pozostają na miejscu, niezależnie od typu kompilacji. Na przykład, jeśli publiczna metoda oczekuje argumentu będącego liczbą w zakresie od 5 do 500, powinien być strzeżony przez ArgumentOutOfRangeException. Nie działa szybko i nie udaje się często używać wyjątków, o ile mi wiadomo, szczególnie gdy argument jest gdzieś popychany i jest używany znacznie później.

Jednak w miejscach, w których wewnętrzny stan przejściowy jest sprawdzany pod kątem stanu zdatności (na przykład sprawdzanie, czy jakiś stan pośredni jest w rozsądnych granicach podczas pętli), wygląda na to, że Debug.Assert jest bardziej w domu. Co jeszcze masz zamiar zrobić, gdy twój algorytm się nie pomyli pomimo przekazania do niego prawidłowych argumentów? Zgłasza wyjątek EpicFailException? :) Myślę, że to właśnie tam Debug.Assert jest nadal przydatny.

Nadal jestem niezdecydowany, jeśli chodzi o najlepszą równowagę między tymi dwoma. Przestałem używać używania Debug.Aserts tak wiele w C# od czasu rozpoczęcia testów jednostkowych, ale wciąż jest dla nich miejsce dla IMO. Na pewno nie użyłbym ich do sprawdzenia poprawności w używaniu API, ale po to, żeby sprawdzić, czy nie ma problemów z dostaniem się do miejsc. Pewnie.

Jedynym minusem jest to, że mogą wyskoczyć i zatrzymać NUnit, ale można napisać wtyczkę NUnit, aby je wykryć i nie wykonać żadnego testu, który uruchamia potwierdzenie.