180

140

Testowanie danych, a nie kodu

rada

Szukanie fragmentu kodu, w którym jest błąd, jest jak szukanie igły w stogu siana. Natomiast odkrywanie miejsc, w których dane zostały źle przetworzone, pozwala na wyśledzenie prawdziwego źródła problemu.

Błędy są wynikiem złego przetworzenia danych. W przeciwnym razie nigdy byśmy się o tych błędach nie dowiedzieli. Nie należy od razu zabierać się do szukania błędów w algorytmie lub w cyklu wykonawczym. Prześledźmy dane w trakcie ich przetwarzania przez kod. Zwracanie uwagi na miejsca, w których dane przyjęły wartości, których nie powinny były przyjąć, pozwoli zrozumieć, gdzie tkwi błąd.

Sprawdzanie wygenerowanego kodu

rada

Ostateczna wersja produktu będzie kodem skompilowanym, a nie kodem źródłowym. Trzeba więc zapoznać się z kodem wygenerowanym w języku maszynowym, a nie tylko z kodem źródłowym. Dzięki temu dowiemy się dokładnie, jak działa program. Nawet jeśli nie używamy kodu maszynowego do usuwania usterek, to zawsze należy spojrzeć na to, co zostało wygenerowane.

Zobacz też: Wskazówka 124.

142

Planowanie testowania

rada

Kod będzie testowany, a przynajmniej powinien być. Pogódźmy się z tym. Polubmy tę czynność. Zaplanujmy ją, ułatwiając sobie to zadanie. Oto kilka rzeczy, które możemy w tym celu zrobić.

•    Przed rozpoczęciem kodowania przejrzeć projekt z ekipą testującą.

•    Zastanowić się nad spełnieniem warunków brzegowych.

•    Napisać kilka prostych testów do sprawdzenia, czy kod działa przynajmniej dla najczęstszych przypadków. Przeprowadzać te testy po każdej modyfikacji kodu.

•    Udokumentować kod.

•    Wstawić zaczepy do kodu interfejsu, tak aby mógł być przetestowany za pomocą automatycznych programów testujących.