Pomyślałem, że dodam jeszcze cztery przypadki, w których Debug.Assert może być właściwym wyborem.
1) Nie wspomniałem tutaj o dodatkowym zasięgu koncepcyjnym, który Asserts może zapewnić podczas testów automatycznych . Jako prosty przykład:
Gdy jakiś program wywołujący wyższego poziomu zostanie zmodyfikowany przez autora, który uważa, że rozszerzył zakres kodu w celu obsługi dodatkowych scenariuszy, najlepiej (!) Napisze testy jednostkowe, aby objąć ten nowy warunek. Może się zdarzyć, że w pełni zintegrowany kod będzie działał poprawnie.
Jednak w rzeczywistości wprowadzono subtelną wadę, ale nie została wykryta w wynikach testu. Odbiorca stał się w tym przypadku niedeterministyczny i zdarza się tylko , że zapewnia oczekiwany wynik. A może spowodował błąd zaokrąglenia, który nie został zauważony. Lub spowodował błąd, który został wyrównany w innym miejscu. Lub przyznany nie tylko żądany dostęp, ale dodatkowe uprawnienia, których nie należy przyznawać. Itp.
W tym momencie instrukcje Debug.Assert () zawarte w odbiorniku w połączeniu z nowym przypadkiem (lub przypadkiem krawędzi) sterowanym przez testy jednostkowe mogą dostarczyć bezcenne powiadomienie podczas testu, że założenia autora zostały unieważnione, a kod nie powinien zostanie wydany bez dodatkowej recenzji. Aserty z testami jednostkowymi są idealnymi partnerami.
2) Dodatkowo, niektóre testy są proste do napisania, ale są drogie i niepotrzebne, biorąc pod uwagę początkowe założenia . Na przykład:
Jeśli dostęp do obiektu można uzyskać tylko z pewnego bezpiecznego punktu wejścia, czy należy wykonać dodatkowe zapytanie do bazy danych praw sieciowych z każdej metody obiektowej, aby upewnić się, że osoba dzwoniąca ma uprawnienia? Na pewno nie. Być może idealne rozwiązanie obejmuje buforowanie lub inne rozszerzenia funkcji, ale projekt tego nie wymaga. Debug.Assert () natychmiast pokaże, kiedy obiekt zostanie dołączony do niepewnego punktu wejścia.
3) Następnie, w niektórych przypadkach, produkt może nie mieć żadnej użytecznej interakcji diagnostycznej dla wszystkich lub części swoich operacji, gdy zostanie wdrożony w trybie wydania . Na przykład:
Załóżmy, że jest to wbudowane urządzenie czasu rzeczywistego. Zgłaszanie wyjątków i restartowanie, gdy napotka zniekształcony pakiet, przynosi efekt przeciwny do zamierzonego. Zamiast tego urządzenie może czerpać korzyści z najlepszej pracy, nawet do poziomu generowania szumu na wyjściu. Może również nie mieć interfejsu człowieka, urządzenia rejestrującego, a nawet być fizycznie dostępny dla człowieka, gdy zostanie wdrożony w trybie zwolnienia, a świadomość błędów najlepiej zapewnić, oceniając ten sam wynik. W tym przypadku liberalne Asercje i dokładne testy przedpremierowe są cenniejsze niż wyjątki.
4) Wreszcie, niektóre testy są niepotrzebne tylko dlatego, że odbiorca jest postrzegany jako wyjątkowo niezawodny . W większości przypadków, im bardziej kod wielokrotnego użytku, tym więcej wysiłku włożono w uczynienie go niezawodnym. Dlatego często występuje wyjątek w przypadku nieoczekiwanych parametrów wywołujących, ale w przypadku nieoczekiwanych wyników wywoływanych - Asert. Na przykład:
Jeśli podstawowa String.Find
operacja stwierdza, że zwróci a, -1
gdy kryteria wyszukiwania nie zostaną znalezione, możesz być w stanie bezpiecznie wykonać jedną operację zamiast trzech. Jeśli jednak rzeczywiście powróci -2
, możesz nie mieć rozsądnego sposobu działania. Przydałoby się zastąpienie prostszego obliczenia tym, które testuje osobno -1
wartość, i nieuzasadnione w większości środowisk wydania, aby zaśmiecić kod testami zapewniającymi, że biblioteki podstawowe działają zgodnie z oczekiwaniami. W tym przypadku Aserty są idealne.