Jak poprawić testowanie własnego kodu [zamknięte]

12

Dzisiaj sprawdziłem zmianę w jakimś kodzie, który okazał się w ogóle nie działać z powodu czegoś głupiego, ale bardzo ważnego. Czuję się z tym bardzo źle i mam nadzieję, że w końcu czegoś się z tego nauczę. Głupie jest to, że robiłem to wcześniej i zawsze powtarzam sobie, że następnym razem nie będę taki głupi ... Potem to się znowu dzieje i czuję się jeszcze gorzej.

Wiem, że powinieneś utrzymywać podbródek i uczyć się na błędach, ale oto rzecz: staram się poprawić, po prostu nie widzę, jak mogę zapobiec tym wydarzeniom.

Więc teraz pytam was: Czy macie pewne podstawowe zasady podczas testowania kodu?

Piotr
źródło
1
Może to pomóc: programmers.stackexchange.com/questions/45479/…
Amir Rezaei

Odpowiedzi:

17

Napisz testy przed wprowadzeniem zmian w kodzie.

Jeśli proponowana zmiana polega na naprawieniu błędu, test powinien zakończyć się niepowodzeniem, demonstrując błąd. Następnie upewnij się, że mija po naprawieniu błędu. Jeśli później napiszesz test i tylko go widziałeś, nie możesz być pewien, że poprawnie przetestował błąd.

Jeśli proponowana zmiana ma zmienić istniejącą funkcjonalność lub dodać funkcję, napisz kilka testów, aby zapewnić dobre pokrycie obszaru kodu, który chcesz zmienić. Upewnij się, że testy te przejdą pomyślnie, zanim zaczniesz zmieniać kod, i nadal będą zaliczane po zakończeniu.

Alba
źródło
To naprawdę dobra rada, usunięcie poprawki może potrwać nieco dłużej, ale cholera, na pewno nie sprawi, że znów popełniam tego rodzaju błędy i pozwoli mi napisać bardziej stabilny kod.
Peter,
@ Peter powinien na dłuższą metę zaoszczędzić czas na konserwację. Powinieneś poświęcić mniej czasu na ręczne testowanie poprawek dymu, a także testy będą miały miejsce przy następnej edycji kodu. Czasami może się okazać, że szybkie napisanie testu jednostkowego, który odtwarza błąd, może przyspieszyć debugowanie i naprawić błąd.
Alb
@ Peter Często powtarzam błąd kilka razy, gdy go naprawiam. Zamiast tego napisanie małego testu zwykle oszczędza czas, nie wspominając o tym, że możesz być absolutnie pewien, że zadziała (i zadziała w przyszłości).
DasIch
to taka fantastyczna rada kolego, dziękuję bardzo!
Shaheer,
@Alb lub nawet w krótkim okresie.
3

Nie zapomnij przetestować najnowszych modeli! Wiele błędów wynika z przetestowania najczęstszych działań, ale nie tych mniej powszechnych.

HLGEM
źródło
Prawdziwym klejnotem Imho jest znalezienie takich skrzynek. Często jestem zaskoczony błędami pochodzącymi z systemu tylko dlatego, że nie pomyśleliśmy o konkretnym scenariuszu.
Peter
2

Postępuj zgodnie ze wskazówkami technicznymi zawartymi w odpowiedziach zorientowanych technicznie; to dobre rzeczy. Moja odpowiedź dotyczy bardziej nastawienia.

Czując się źle, popełniając rodzaj błędu, który każdy programista popełnia czasami, jest po prostu absurdalny i nie pomaga ci nie popełnić tego rodzaju błędu w przyszłości. Siedząc tam, czując się źle, kompilacja jest wciąż zepsuta, wiesz? A potem twoja praca polega na unikaniu błędów, które, jak wiem, sprawiają, że wstawanie z łóżka każdego dnia jest ekscytującą przygodą, prawda?

Słyszałem o firmach, w których sprawdzanie uszkodzonego kodu jest powodem do publicznego zawstydzania. Nie potrafię nawet pogodzić się z takim wypaczonym, braterskim chłopcem, myśleniem na wysokim szczeblu, które prowadziłoby do takiego zachowania. Lider zespołu lub menedżer nie może mieć ŻADNEGO efektu przeciwnego do zamierzonego.

Więc nie pobijaj się. Wszyscy to zrobiliśmy. Prawdopodobnie kosztują mnie pół dnia w tygodniu na głupie błędy i robię to od dłuższego czasu (kaszel). Tak wygląda pisanie kodu - nieustannie walczysz z czymś, co wydaje się być Twoją własną niedoskonałością. Tym, co czyni profesjonalistę profesjonalistą, nie jest mityczna cecha, że ​​nigdy nie popełnia błędów (w tym czasem dużych), ale sposób, w jaki ODPOWIADA na popełnione błędy.

Jeśli jest jedna mantra, którą mógłbym zaszczepić w każdym programiście, z którym współpracuję, jest to: Nie jesteś swoim kodem . Piszesz kod. Piszesz to tak dobrze i efektywnie, jak tylko potrafisz. Potem idź do domu. Jeśli utożsamiasz swoją wartość lub poczucie własnej wartości jako osoby z jakością swojego kodu, po prostu brakuje ci łodzi o tym, kim naprawdę jesteś.

Dan Ray
źródło
Rozumiem, co mówisz o publicznym zawstydzaniu, ale jednocześnie frustracja jest blokowana, ponieważ kompilacja jest zepsuta, ponieważ Joe Bloggs nie zbudował wszystkich platform przed
odprawą
@tenpn - całkowicie. Ale druga strona tego, co mówię, dotyczy również Joe Bloggsa. On też nie jest jego kodem. Jako koledzy musimy oprzeć się impulsowi, aby w naszych oczach Joe stał się idiotą, ponieważ popełnił błąd, który mógł popełnić każdy z nas.
Dan Ray
@tenpn faktycznie, możesz również winić system za to, że nie testował automatycznie kompilacji przed zatwierdzeniem zmian w linii głównej / głównym.
David
2
@tenpn - Żadne z nich nie bije współpracowników.
Dan Ray
1
Co jeśli zmiana nie zepsuje kompilacji? Budowanie kodu przed zalogowaniem jest rozsądne. Testowanie kodu na wszystkie możliwe sposoby nie jest tak oczywiste. Zawsze jest jakiś scenariusz, o którym nie mogłeś pomyśleć. Właśnie dzisiaj natrafiłem na błąd zaokrąglania zmiennoprzecinkowego, który zdarza się tylko wtedy, gdy masz prawidłowe (niewłaściwe) liczby
Peter
2

Inną ważną praktyką testowania jest napisanie testu i upewnienie się, że nie powiedzie się przynajmniej raz PRZED napisaniem kodu. Łatwo jest zepsuć i napisać test tautologiczny, który przypadkowo nie testuje sprawdzanego stanu. Fałszywe zapewnienia są prawie (a czasem gorsze) niż żadne zapewnienia.

Uri
źródło
0

Jednym z pomysłów, z którego korzystałem od czasu do czasu, jest:

utwórz gałąź i zepsuj kod, uruchom test i upewnij się, że test wykryje błąd.

Zachary K.
źródło
0

Czy masz pewne podstawowe zasady podczas testowania kodu?

  • Zawsze testuj kod jednostkowo i staraj się osiągnąć jak najwyższy zasięg.

Kilka dodatkowych punktów ogólnych:

  • zainwestuj trochę czasu w projektowanie i planowanie przed rozpoczęciem kodowania
  • refaktoryzuj swój kod!
BЈовић
źródło