Jak skutecznie programować, gdy testowanie kodu zajmuje dużo czasu?


16

Mój obieg pracy zawsze polegał na napisaniu jednego logicznego kroku, a następnie uruchomieniu programu i sprawdzeniu wyniku. Ten proces bardzo mi pomógł w przypadku zadań na uniwersytecie. Jednak wraz z dalszym rozwojem często zdarza się, że skompilowanie i uruchomienie kodu zajmuje od 1 do 2 minut. Przykłady obejmują przesyłanie programu do mikrokontrolera, wymagające interakcji z zewnętrznym serwerem i niemożności wdrożenia automatyzacji z powodu uwierzytelnienia, architektury oprogramowania lub złożoności.

Tego typu zadania są bardzo nieodpowiednie do tego, jak zwykle programuję, i mam trudności z efektywnym kodowaniem. Zwykle popełniam wiele błędów składniowych i błędów logicznych, z których większość łatwo wychwytuję testując. Jednak przy tak długim czasie oczekiwania ta metoda jest zbyt czasochłonna.


Czy używasz IDE?
Woot4Moo,

3
Problem root nie polega na tym, że nie jest w stanie skutecznie kodować, to testy trwają zbyt długo. Zadajesz złe pytanie.
Rein Henrichs,

Użyj języka, który ma REPL.
Robert Harvey

Czy masz kolegów, których możesz prosić i uczyć się od nich?
user985366,

Odpowiedzi:


25

Po pierwsze, wszelkiego rodzaju interaktywne debugowanie jest świetne. Chcesz tego w swoim zestawie narzędzi, ponieważ jeśli nie, to pewnego dnia naprawdę skorzystasz z niego. (Szczegóły różnią się w zależności od języka, platformy i IDE).

wymagające interakcji z zewnętrznym serwerem i niemożności wdrożenia automatyzacji z powodu uwierzytelnienia, architektury oprogramowania lub złożoności.

Chciałbym przyjrzeć się niektórym ramom do używania próbnych obiektów . Pozwalają one otoczyć testowany komponent fałszywym ekosystemem innych komponentów, dzięki czemu testy są bardziej ukierunkowane i można uniknąć testowania wszystkiego jako całości.

Ponadto same obiekty pozorne mogą być programowane za pomocą asercji, dzięki czemu można sprawdzić, czy testowany komponent naprawdę wykonał określone wywołanie.


12

Ciężko pracowałbym, aby skrócić czas testu. Pracowałem w kilku firmach opracowujących kod wbudowany, a testowanie było bolesne, wymagało podróży do serwerowni oraz ręcznych FTP i restartów oraz wielu poleceń na sprzęt testowy. Potem dołączyłem do naprawdę dobrej grupy, w której mogłem po prostu wpisać „wykonaj test” na biurku i uzyskać wyniki w niecałą minutę. W tej minucie:

  • Mój kod został wbudowany w nowy obraz jądra dla wbudowanego sprzętu.
  • Serwer DHCP został zaktualizowany, aby wskazywał na nowe jądro.
  • Płyta testowa została ponownie uruchomiona.
  • Płyta testowa pobrała jądro z mojej stacji roboczej poprzez podłączenie NFS.
  • Płyta testowa uruchomiła się ponownie w nowym jądrze.
  • Przeprowadzono testy jednostkowe.
  • Wyjście testu jednostkowego zostało dostarczone z powrotem na moją stację roboczą.

Zajęło to trochę czasu, aby wszystko to działało, ale wysiłek automatyzacji wszystkich tych kroków został odzyskany stukrotnie, w miarę wzrostu personelu programistycznego.


2
+1. Nie ma problemu, którego nie można rozwiązać za pomocą wystarczającej ilości skryptu powłoki.
Tom Anderson

1
Nie pozostanę w zespołach, które nie dbają o poprawę prędkości.
kevin cline

@Tom Z wyjątkiem zbyt wielu warstw skryptów powłoki;)
Darien

Nie, po prostu piszesz skrypt powłoki, który otacza drugi skrypt powłoki. Jest tylko jeden skrypt powłoki. ZAUFAJ MI.
Tom Anderson

3
+1: Poprawa prędkości edycji -> kompilacja -> ładowanie -> uruchamianie -> debugowanie -> edycja to jedna z najlepszych rzeczy, które możesz zrobić, aby przyspieszyć produkcję kodu. Kiedy pracowałem w Tymshare, mieliśmy faceta, który twierdził (poprawnie), że jego kod działał poprawnie przy pierwszej próbie 87% czasu. Ja, z drugiej strony, zakodowałem, jakbym przedawkował małpę kofeinową o 1 w nocy (którą byłem). Popełniłem mnóstwo błędów literówek itp., Ale nie martwiłem się nimi, ponieważ wiedziałem, że kompilator je złapie. Pod koniec dnia byłem prawdopodobnie 3 do 5 razy bardziej produktywny niż on.
Peter Rowell,

8

Zautomatyzowane testy nie zastępują przeglądu i zrozumienia.

Być może używasz testów jako kuli. Jeśli to zrobisz, utrudnisz naukę. Nie zalecam, żebyś nie testował. Zamiast tego polecam, aby przed uruchomieniem testu sprawdzić, co napisałeś. Zrozum, co napisałeś, upewnij się, że ma to sens i upewnij się, że składnia wygląda poprawnie.


5

Już dałeś odpowiedź: I usually make a lot of syntax errors and logic errors

Dlatego ciężko pracując nad poprawą tego, powinieneś być w stanie skrócić czas testowania. Błędy składniowe powinny być pierwszymi, które należy zmniejszyć. Nigdy nie studiowałeś testu programistycznego z papierem i ołówkiem?

Miałem to samo, kiedy przestawiłem się z PHP na Javę. Musiałem nauczyć się debugować zamiast tylko drukować niektóre zmienne i naciskać F5 w przeglądarce ...


2
Wszyscy od czasu do czasu popełniamy głupie błędy, które pojawiają się rzadziej z czasem i doświadczeniem.
wałek klonowy

@maple_shaft to prawda, ale kiedy mówi make a lot of, że to brzmi jak powinien zainwestować swoją energię, aby to poprawić
WarrenFaith

3
Zrobiłem sporo kodowania na papierze i na tablicach. Problem jest taki sam: kod wygląda poprawnie przy pierwszej inspekcji, ale po uruchomieniu zauważasz swoje błędy.
Anne Nonimus

zauważanie błędów w kodzie i pisanie kodu z niewłaściwą składnią to duża różnica. Pierwszy może przydarzyć się każdemu, drugi sugeruje poziom dla początkujących. Nie znam twojego pochodzenia, ale nawet jako początkujący powinieneś minimalizować problemy ze składnią. Jaki jest twój IDE i język? Powinien obsługiwać sprawdzanie składni.
WarrenFaith

@Anne Nonimus: Masz na myśli błędy logiczne? Błędy składniowe powinny być wychwytywane przez twoje IDE (najlepiej - jeśli pracujesz z kodem, który jest generowany dynamicznie, wtedy te błędy składniowe nie zostaną wykryte w czasie kompilacji).
FrustratedWithFormsDesigner

4

Potrzebujesz dobrej platformy testowej Unit lub Functional, która może automatycznie uruchamiać testy, najlepiej w tle. Będzie to wymagało użycia Mocków, jak wspomniano powyżej, i w zależności od języka, w którym używasz jakiegoś zastrzyku zależności.

Dzięki uczynieniu obiektów możliwie najbardziej niezależnymi, a następnie zastosowaniu metod wstrzykiwania w celu dodania zewnętrznych ograniczeń, nie jest trudno stworzyć platformę testową dla swojego kodu.


2

Prawdziwa zabawa przychodzi, gdy po prostu nie możesz przetestować swojego kodu, chyba że używasz go w gniewie. Zdarza się to dość często w przypadku systemów transakcyjnych, ponieważ dostępne symulatory wymiany są często albo słabe, nie istnieją, albo nawet nie są zgodne z tym, co mówią dostawcy oprogramowania do wymiany. Obawiam się, że to część bogatej tkaniny życia. Moje podejście polega na upewnieniu się, że przynajmniej moja strona transakcji jest dobrze napisana i dobrze udokumentowana, dzięki czemu można ją łatwo zmienić szybko.


3
„Wymieniasz” i „handlujesz” inżynierami oprogramowania są wyjątkową rasą. Mój przyjaciel miał serię załamań psychicznych pracujących dla jednej z takich firm. Nigdy nie słyszę, aby dobre rzeczy wychodziły z tej niszy branży oprogramowania.
wałek klonowy

@maple Cóż, sam tego nie robię. Ale wyjątkowy? Nie - każdy może pisać kiepski kod, a większość kodu handlowego jest głęboko, głęboko kiepska. Jednak to nam się podoba, czy nie, jest podstawą naszego społeczeństwa.
Neil Butterworth,

Tak, słyszałem to samo o kodzie telekomunikacyjnym i ile milionów linii było w oprogramowaniu do sterowania przełącznikami. Potem dołączyłem do firmy telekomunikacyjnej i zdałem sobie sprawę, że gdyby zatrudniali programistów, wystarczyłyby tysiące linii.
kevin cline

2

Testów jednostkowych; Fikcyjne aplikacje / symulatory.

To zabierze trochę czasu, oczywiście, i może być konieczne zebranie i masowanie przykładowych danych w celu stworzenia odpowiednich makiet, ale w końcu się to opłaci: Zaoszczędzisz sobie cały czas i problemy, które napotkasz, próbując przetestować na zewnętrznym systemy.

Użyte prawidłowo, narzędzia te zapewnią, że zanim przejdziesz gdziekolwiek w pobliżu systemów zewnętrznych, będziesz w 99,9% pewien, że jeśli twój kod zawiedzie, to coś w systemie zewnętrznym / zmiana środowiska, które go spowodowało, a nie błąd w twoim własnym kodzie.

Przez pewien czas pracowałem zawodowo tak jak ty w szkole, aw wielu przypadkach było to bardzo skuteczne. W końcu pracowałem u niektórych osób, które zmusiły mnie do porzucenia tej metodologii i zamiast tego skorzystałem z testów jednostkowych i makiet.

Teraz nie rozpoczynam żadnego projektu bez wcześniejszego przemyślenia wdrożenia faz testowania - testowanie jednostkowe, makiety, symulatory, przykładowe dane itp.


1

Zwykle popełniam wiele błędów składniowych i błędów logicznych

Może użycie Lintera może ci trochę pomóc.

Byłem w podobnej sytuacji z moim poprzednim pracodawcą. Nasza baza kodu była naprawdę ogromna i aby wprowadzić wszelkie zmiany, które musiałem kodować, skompiluj, a następnie zamień .classpliki na serwerze deweloperskim, a następnie zrestartuj dev-sever za pomocą skryptu restartu. Ku mojemu przerażeniu ponowne uruchomienie serwera deweloperskiego zajmie około pół godziny.

Później dowiedziałem się, że zdalne debugowanie serwera deweloperskiego było również możliwe.

Oto co zrobiłem, aby zoptymalizować mój proces

  • Pierwsza wstępna runda zdalnego debugowania pozwoliła mi zobaczyć dokładny przepływ kodu i dokładne wartości / stany zmiennych.

  • Planowanie, jak i jakie zmiany wprowadzę.

  • Wprowadzanie zmian, a następnie porównywanie różnic

  • Błędy buforowania przy użyciu linijki lub kompilacji.

  • Przekazywanie poprawki przez zastąpienie .classplików i ponowne uruchomienie.

Czasami dołączałbym też bardzo dużo instrukcji dziennika, aby ponownie sprawdzić przepływ kodu i sprawdzić wartości / stany. To bardzo mi pomogło.

Również użycie IDE z dobrą automatyczną komplikacją może znacznie pomóc w zmniejszeniu literówek.

Mam nadzieję że to pomoże.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.