Naprawdę nie ma sposobu, aby upewnić się, że twoje przypadki testowe są poprawne, z wyjątkiem bardzo dobrego skoncentrowania się podczas ich tworzenia - zrozumienia wymagań, zrozumienia kodu i upewnienia się, że się zgadzają. Kluczem do posiadania zestawu testowego jest to, że musisz to zrobić tylko raz, i od tego momentu możesz po prostu ponownie wykonać testy i sprawdzić, czy pomyślnie przejdą, podczas gdy bez zestawu testowego musiałbyś cały czas bardzo mocno się koncentrować , tj. za każdym razem, gdy robisz cokolwiek z bazą kodu. Ale podstawowy problem polegający na upewnieniu się, że robisz właściwie, to przede wszystkim - komputery po prostu nie są wystarczająco inteligentne, aby uwolnić nas od tego zadania.
Dlatego (1) jeśli zestaw testów jest niekompletny, nie ma prostego sposobu, aby to zobaczyć. Analiza pokrycia kodu może udowodnić, że niektóre wiersze kodu nigdy nie są wykonywane, tj. Że pakiet jest w jakiś sposób niewystarczający, ale nie w jakim stopniu jest to niedobór i nigdy nie może udowodnić, że jest wystarczający. Nawet przy 100% pokryciu kodu nie masz gwarancji, że wszystkie odpowiednie stanysystemu są wykonywane, a pełne pokrycie stanu jest nieosiągalne dla każdego realistycznego systemu ze względu na kombinatoryczną liczbę stanów, które mogłyby istnieć. Jedną z dobrych technik upewnienia się, że testowany przypadek jest co najmniej poprawny do sprawdzania tego, co chcesz sprawdzić, jest napisanie testu, sprawdzenie, czy rzeczywiście się nie powiedzie, napisanie / zmiana kodu, a następnie sprawdzenie, czy teraz przejdzie pomyślnie. Stąd entuzjazm do programowania opartego na testach: pozwala mieć całkowitą pewność, że indywidualny test działa poprawnie, a jeśli stworzysz w ten sposób całą bazę kodu, możesz uzyskać podobny poziom zaufania nawet w dużym systemie.
(2) Zestaw testów zwykle staje się niewystarczający, gdy zmieniają się wymagania - nie musisz zgadywać. Jeśli klient chce, aby określone zachowanie uległo zmianie, a testy zakończyłyby się powodzeniem zarówno przed zmianą, jak i po niej, najwyraźniej nie stosowały one tej konkretnej relacji wejścia / wyjścia.
Jeśli chodzi o starsze systemy, które nie mają pokrycia testowego lub tam, gdzie nie wiesz, jaki jest zakres pokrycia, nie ma formalnego dowodu, ale (doradztwo rodziców: wynika z osobistej opinii!) Mówiąc z doświadczenia, jest bardzo prawdopodobne, że testy nie są odpowiednie. Kiedy testowanie jest postrzegane jako po fakultatywnym, opcjonalnym, poprawiającym jakość, ale niekoniecznie koniecznym działaniu, jest on zwykle niekompletny i niesystematyczny, ponieważ motywacja do upewnienia się, że testy nadążają za bazą kodu, po prostu nie jest tam jest.