Dodaj test jednostkowy dla każdego nowego błędu

W mojej pracy wszyscy programiści, którzy usuwają błąd, muszą dodać nowy test jednostkowy, który ostrzega przed tego typu błędami (w przypadku, gdy wystąpi ponownie). Jeśli test jednostkowy nie jest możliwy (na przykład problem z projektem strony internetowej), dział kontroli jakości musi utworzyć przypadek testowy, aby go ręcznie sprawdzić.

Chodzi o to, że jeśli defekt nie został wykryty przed wydaniem produktu, to dlatego, że nie ma odpowiedniego testu jednostkowego, aby go wykryć. Deweloper musi to dodać.

Pytanie brzmi: czy jest to powszechne w jakiejkolwiek metodologii tworzenia oprogramowania? Ta technika ma nazwę? Chciałbym dowiedzieć się więcej na ten temat, ale na początek potrzebuję informacji.

Jest to dość powszechne. Używamy tego w naszym zespole. W przypadku każdej wady produkcyjnej programista musi dodać notatkę na temat pierwotnej przyczyny problemu, dodać test jednostkowy, który nie powiódł się, i dodać analizę wpływu testu, zanim bilet będzie mógł zostać przekazany do stanu deweloperskiego w celu sprawdzenia kodu.

Niepowodzenie testu jednostkowego musi przejść pomyślnie, zanim będziemy mogli przekazać kod do produkcji.

Nie sądzę, aby miało to konkretną nazwę, z wyjątkiem tego ogólnego „testu regresji”. Jest to bardzo przydatne i po rozpoczęciu tego procesu zaczęliśmy zauważać wzrost jakości produktu.

Absolutnie!

Jeśli zgodzisz się, że testy jednostkowe są dobre, zdasz sobie sprawę, że jeśli wystąpi błąd, brakuje testu jednostkowego obejmującego tę ścieżkę kodu.

Więc co powinno się zdarzyć, napisz test jednostkowy, który pokazuje, że błąd istnieje, napraw rzeczywisty błąd, a następnie test jednostkowy przejdzie.

Jeśli nie masz żadnych testów jednostkowych, może to być dobry sposób na rozpoczęcie testów jednostkowych w projekcie.

Technika ta opiera się na testowaniu. Tak naprawdę nie chodzi o to, aby następnym razem wykryć podobny błąd, chociaż zestaw powtarzalnych testów jest zawsze pomocny. Chodzi o to, że możesz wykazać, że odizolowałeś co jest nie tak z kodem, udowodniłeś, że jest źle, naprawiłeś go, udowodniłeś, że poprawka jest poprawna.

Jest cytat, którego nie mogę sobie przypomnieć ani znaleźć, ale z grubsza jest to: „Każdy błąd jest testem, który nie został jeszcze napisany”.

Próbowanie sprzedaży jako testu regresji to przegrana bitwa, IMHO. Biorąc pod uwagę, jak często te rzeczy łapią powtarzający się błąd, większość programistów mówi po prostu: „Po co zawracać sobie głowę, kiedy mogę to po prostu naprawić?”.

Ta technika jest dość powszechna i, moim zdaniem, najlepszą nazwą jest „Testowanie oparte na defektach” (sam ją wymyśliłem, a dawno temu znalazłem opisany pod tą nazwą ).

Czasami może się zdarzyć, że niektórzy nazywają te testy „Testami regresji”, ale osobiście trudno mi uzasadnić tę nazwę. Nieco bardziej rozpowszechniona definicja (i ta, która prawdopodobnie ma o wiele więcej sensu dla tej nazwy) „testowanie regresyjne” to „uruchamianie testów po wprowadzeniu jakichkolwiek zmian w kodzie, aby upewnić się, że nie wprowadzono żadnych regresji” i twojego CI który testuje każdą gałąź po wypchnięciu do repozytorium, spełnia ją.