Zrobiłem moje pierwsze kroki dla dzieci w testowaniu jednostek i, dzięki lepszemu zrozumieniu domeny, dokonałem zmiany w modelu domeny, który zepsuł test jednostkowy. W związku z tym pojawiło się pytanie:Kiedy można zmienić "zakończone" testy jednostkowe?
Kiedy można zmienić poprzednio działające testy jednostkowe?
ja figura mi brakuje ważny aspekt testów jednostkowych w konieczności zadać to pytanie ...
W przypadku "właściwego" TDD należy najpierw zmienić test, , a następnie zmienić kod.
Tak naprawdę ty nigdy ma uszkodzone testy, tylko zepsuty kod. Zawsze powinieneś starać się być w pozycji, w której testy są ostatecznym wyrazem prawidłowej funkcjonalności i jako takie są a priori poprawne.
Zależy w pewnym stopniu od zasięgu kodu testów –
+1. Słuszna uwaga! –
ah, ale zmiana jednego testu, aby umożliwić zmianę, może nadal łamać inne testy z uzasadnioną poprawnością po zmianie, co oznacza, że będziesz musiał później zmienić inne testy. – Sekhat
Po dokonaniu zmian, które łamie testy:
1) Najpierw sprawdź, czy test jest teraz zepsuty lub twoja zmiana spowodowała zerwanie testu, którego nie powinno mieć.
2). Jeśli to ta pierwsza, napraw test. Else popraw zmianę.
Punktem każdego testu jednostkowego nie jest to, że nigdy się nie zepsuje, ale że nadal działa tak długo, jak działa funkcja, której testuje. W ten sposób przypadkowa zmiana w testowanej funkcji powoduje, że nieudany test zostanie wykryty, a nie użytkownik końcowy.
Jeśli funkcja została celowo zmieniona, należy spodziewać się przerw w testach. Jeśli tego nie zrobisz, nie masz wystarczającego zasięgu funkcji w pakiecie testowym.
Gdy zmieniają się wymagania. Niezależnie od tego, czy zmienisz kod, a następnie zobaczysz, które testy przerwano z jakiego powodu (zgodnie z sugestią Mitcha), lub zmienisz testy, a następnie zmienisz kod (jak pokazano w Wizażu), testy zostaną zmienione tylko wtedy, gdy funkcja ma wartość ., aby zrobić coś innego.
Za każdym razem, gdy trzeba.
Chodzi o to, że twoje testy powinny być dokładnym obrazem tego, jak powinno działać twoje oprogramowanie. To prawda, że będzie to trochę trudne do utrzymania, a faktycznie jest to jedno z większych wyłączeń z TDD, drugie po testowaniu - pierwsze programowanie.
Testy są specyfikacją zachowania programu. Zmieniasz je, gdy musisz zmienić specyfikacje, ponieważ są to specyfikacje. Niektórzy przychodzą mi na myśl ...
Podstawową jakością kodu testowego musi być czytelność. Dlatego powinieneś regularnie zmieniać testy z powodu ...
Są również przypadki, w których testy są przerywane, na przykład testy kruche dla kodu współbieżnego, który przeważnie przechodzi, ale co jakiś czas się nie udaje, mimo że kod jest poprawny. W takich przypadkach testy powinny być ustalone tak, aby były bardziej powtarzalne (może wymagać zmiany kodu, aby łatwiej było je testować - najlepiej jest unikać/ograniczać współbieżność z odpowiednimi wzorami projektowymi).
Doskonałe pytanie. –