Jak ludzie utrzymują swój zestaw testów?

W szczególności jestem ciekawy następujących aspektów:

1. Skąd wiesz, że twoje przypadki testowe są nieprawidłowe (lub nieaktualne) i wymagały naprawy (lub odrzucenia)? Chodzi mi o to, że nawet jeśli przypadek testowy stałby się nieważny, może nadal przechodzić i milczeć, co może pozwolić ci fałszywie uwierzyć, że twoje oprogramowanie działa poprawnie. Jak więc zdajesz sobie sprawę z takich problemów w swoim zestawie testów?

2. Skąd wiesz, że Twój zestaw testów nie jest już wystarczający i że należy dodać nowe przypadki testowe? Myślę, że ma to coś wspólnego ze zmianami wymagań, ale czy istnieje jakieś systematyczne podejście do sprawdzania adekwatności zestawu testów?

Krótka odpowiedź: użyj znanych narzędzi, które pomagają utrzymać jakość przypadków testowych, takich jak następujące narzędzia do pokrycia kodu i jakości kodu: Cobertura, PMD, Sonar itp., Które pomogą Ci zauważyć, kiedy krytyczny komponent programu nie jest wystarczająco przetestowany. Napisz też testy integracji, które najprawdopodobniej pękną jako pierwsze, gdy coś pójdzie nie tak.

Długa odpowiedź:

Skąd wiesz, że twoje przypadki testowe są nieprawidłowe (lub nieaktualne) i wymagały naprawy (lub odrzucenia)? Chodzi mi o to, że nawet jeśli przypadek testowy stałby się nieważny, może nadal przechodzić i milczeć, co może pozwolić ci fałszywie uwierzyć, że twoje oprogramowanie działa poprawnie. Jak więc zdajesz sobie sprawę z takich problemów w swoim zestawie testów?

• Korzystając z narzędzi pokrycia kodu, takich jak Cobertura , możesz wykryć, że przypadki testowe dla danej klasy lub złożone metody nie są już wystarczające. Nie musisz wszędzie osiągać 100% pokrycia kodu, aw większości przypadków będzie to trudne do osiągnięcia i niekoniecznie przydatne; ale testy najbardziej krytycznych aspektów programu powinny być utrzymywane w celu co najmniej 80% pokrycia kodu.
• Korzystając z narzędzi do ciągłego budowania i integracji , takich jak Jenkins, które bardzo lubię, w połączeniu z wtyczką Sonar , możesz ustawić wyzwalacze, które wysyłają e-maile i inne typy alertów do osób odpowiedzialnych za najnowsze zmiany. Różne wykresy i statystyki (Sonar używa również Cobertury wśród wielu innych narzędzi) pomagają recenzentom kodu i twórcom przypadków testowych skupić się na tym, co najważniejsze.

Skąd wiesz, że Twój zestaw testów nie jest już wystarczający i że należy dodać nowe przypadki testowe? Myślę, że ma to coś wspólnego ze zmianami wymagań, ale czy istnieje jakieś systematyczne podejście do sprawdzania adekwatności zestawu testów?

To, co napisałem na pierwsze pytanie, stanowi część odpowiedzi na twoje drugie pytanie. Dodam również następujące punkty:

• Napisz przypadki testowe integracji (lub „biznesowe”, jeśli wolisz) oprócz przypadków testowych. Najprawdopodobniej zmieniają się / psują najpierw, ponieważ często zależą od wielu klas / metod. A ponieważ często się psują, jest mniej prawdopodobne, że zostaną zapomniane. Jedynym podejściem / metodologią, która z mojego osobistego doświadczenia pomaga pisać dobre testy, jest Test-Driven Development . Zwłaszcza jeśli osoba pisząca przypadek testowy NIE jest tą samą osobą, która pisze dla niego kod. Pisanie dobrych przypadków testowych przy użyciu TDD również wymaga czasu, ale wyniki, przynajmniej dla mnie, były bardzo zadowalające.
• Ilekroć pojawia się błąd, napisz poprawkę i dołączony do niej testowy przypadek. Przypadek testowy powinien obejmować tylko ten konkretny błąd. Ponieważ całkowicie zakryłeś kod odpowiedzialny za błąd, nie powinien się on pojawiać ponownie.

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.