TDD tylko w teorii

29

Nieco ponad rok temu miałem szczęście, że mogłem zrobić 9-miesięczną przerwę w pracy. Zdecydowałem, że w tym czasie doskonalę swoje umiejętności w języku C #. Zacząłem pracować nad wieloma projektami i zmusiłem się do śledzenia TDD.

To był dość pouczający proces.

Na początku było ciężko, ale z czasem nauczyłem się pisać bardziej testowalny kod (który, jak się okazuje, jest bardziej kodem SOLID), a w trakcie tego procesu doskonaliłem umiejętności projektowania OO.

Teraz wróciłem do siły roboczej i zauważam coś dziwnego.

Wolę nie stosować się do TDD.

Uważam, że TDD spowalnia mnie i sprawia, że ​​trudniej jest zaprojektować czystą aplikację.

Zamiast tego zastosowałem nieco (masowo) inne podejście:

  1. Wybierz pionowy kawałek pracy
  2. Opracuj działający prototyp
  3. Refaktoryzuj, aż wszystko będzie ładne i uporządkowane
  4. Usiądź i doceń pięknie napisany przeze mnie SOLIDNY ​​i testowalny kod.

Być może zauważyłeś, że krok 1 nie „zdefiniował publicznej powierzchni mojego testowego celu”, a krok 2 nie „przetestował bejesusa z tej publicznej powierzchni”. Być może zauważyłeś również, że żaden z kroków nie obejmuje testowania. Piszę testowalny kod, ale go jeszcze nie testuję ... jeszcze.

Teraz chciałbym wyjaśnić, że tak naprawdę nie rezygnuję z żadnych testów. Kod, który piszę, działa . Działa, ponieważ testuję to ręcznie.

Chciałbym również wyjaśnić, że nie rezygnuję też ze wszystkich testów automatycznych. To jest mój proces jest inny. I dlatego zadaję to pytanie.

TDD w teorii. Nie w praktyce.

Mój proces ewoluował nieco i osiągnąłem równowagę między TDD a brakiem testów, które uważam za bardzo produktywne i racjonalnie bezpieczne. Wygląda to następująco:

  1. Wykonaj działający pionowy kawałek pracy z myślą o testowaniu, ale nie pisz żadnych testów.
  2. Jeśli później (np. Miesiąc później) ten kawałek wymaga modyfikacji
    1. Napisz testy jednostkowe, testy integracyjne, testy behawioralne itp., Które gwarantują, że fragment pracy jest poprawny
    2. Zmodyfikuj kod
  3. Jeśli ten kawałek nie wymaga modyfikacji,
    1. Nic nie robić

Po prostu przenosząc ciężar pisania testów przed napisaniem kodu na przed modyfikacją kodu, byłem w stanie stworzyć znacznie więcej działającego kodu. A kiedy zaczynam pisać testy, piszę o wiele mniej, ale pokrywam prawie tyle samo gruntu (wyższy ROI).

Podoba mi się ten proces, ale obawiam się, że może nie być dobrze skalowany. Sukces zależy od tego, czy programiści starają się pisać testy przed zmianą. I to wydaje się dość dużym ryzykiem. Ale TDD ma takie samo ryzyko.

Czy więc zamierzam [BT] DD do diabła, czy jest to powszechna forma pragmatycznego kodowania i testowania?

Chciałbym dalej pracować w ten sposób. Co mogę zrobić, aby ten proces działał na dłuższą metę?

Uwaga:

Jestem jedynym programistą w moich projektach i jestem odpowiedzialny za wszystko: zbieranie wymagań, projektowanie, architekturę, testowanie, wdrażanie itp. Podejrzewam, że właśnie dlatego mój proces działa.

MetaFight
źródło
2
Wygląda jak skok i stabilizacja bez wykonywania stabilizacji, jeśli If that slice doesn't need modification. lizkeogh.com/2012/06/24/beyond-test-driven-development
RubberChickenLeader
13
Odkrywasz coś o TDD, o którym od dawna podejrzewałem, że pierwsza testowa mantra jest wyjątkowo dobrym narzędziem do nauki, ale nie jest to projekt, tylko zachęca do dobrego projektu. Ostatecznie to, czego chcesz, to testowalne kody i testy jednostkowe, które zapewniają dobre pokrycie kodu i odzwierciedlają wymagania oprogramowania; jak się dowiadujesz, możesz to osiągnąć bez uprzedniego napisania testów , jeśli będziesz praktykować rozsądne zasady projektowania.
Robert Harvey
5
Tak, i pisanie testów zasadniczo podwaja twoją pracę prototypową.
Robert Harvey
3
oznacza to, że kłamałem o tym, że jest „lekko”.
MetaFight,
1
„A kiedy zaczynam pisać testy, piszę o wiele mniej, ale pokrywam prawie tyle samo gruntu (wyższy zwrot z inwestycji)”. Kiedy mówisz, że pisz znacznie mniej, masz na myśli to, że testujesz tylko kod ” zmienia się, czy mówisz, że w jakiś sposób pokrywasz ten sam (przetestowany) fragment kodu za pomocą mniejszej liczby testów, niż gdybyś używał TDD?
Ben Aaronson,

Odpowiedzi:

6

Aby proces działał w dłuższej perspektywie, pisałbym testy podczas pisania kodu.

Co może wydawać się sprzeczne z twoim podejściem. Jednak zadałeś pytanie, więc dam ci moje zdanie:

Nie musisz pisać testów przed kodem. zapomnij o tej czystości. Jednak chcesz napisać testy w tym czasie.
Gdy już uruchomisz kod, poprawiłeś go trochę, usunąłeś kilka błędów (mówimy tutaj o skali godzin), jesteś wtedy na poziomie maksymalnej wiedzy na temat tego, co robi kod. To świetny czas na pisanie testów, które zdobędą Twoją wiedzę.

Pozostawienie tego na później oznacza, że ​​wiedza (naturalnie) z czasem się zmniejszy.

Oznacza to również, że jeśli kiedykolwiek odejdziesz, a ktoś inny przejmie cię, nie będziesz miał natychmiastowego technicznego długu wynikającego z braku udokumentowania (poprzez testy) tego, co robi.

Przede wszystkim „pewnego dnia” może nie nadejść. Możesz zostać potrącony przez autobus lub wsiąść do autobusu na nowe przygody.

Wreszcie, testy ręczne nie są skalowane i często nie obejmują wszystkich urządzeń używanych przez użytkownika końcowego.

Michael Durrant
źródło
Myślę, że podoba mi się twoje sugerowane podejście i prawdopodobnie zastosuję je, kiedy będę mógł. Moja praca jest jednak bardzo rozdrobniona, więc „harmonogram godzin” nie zawsze jest możliwy. Niestety jestem też wspierany, więc często biorę pracę, aby pomóc w zwalczaniu pożarów :) Ale takie jest życie.
MetaFight,
Problem w tym, że jutro nigdy nie nadejdzie, zawsze będzie następna funkcja. A co zamierzasz zrobić; napisz następną funkcję lub napisz testy dla rzeczy, którą właśnie skończyłeś?
Andy
9

Mimo że TDD jest trudny do wdrożenia w 100%, twoje podejście ma wadę

  1. Wykonaj działający pionowy kawałek pracy

    1.1 1 rok mija ....

    1.2 Nowy programista rozpoczyna prace nad projektem

  2. Jeśli ten kawałek wymaga modyfikacji

    2.3 Analiza składni nazw i parametrów metody „Czyste kodowanie” „GetUnicorn (colourOfUnicorn)”

    2.4 Przeczytaj komentarze xml „Dostaje złotego jednorożca (do jazdy) (obvs)”

    2.5 Odszukaj oryginalnego twórcę

    2.6 Mam nadzieję, że pamiętają, co powinien zrobić kod

    2.7 Poproś ich o wyjaśnienie wszystkiego

  3. Napisz testy jednostkowe, testy integracyjne, testy behawioralne itp., Które , mam nadzieję, zagwarantują, że fragment pracy jest poprawny

  4. Zmodyfikuj kod

Myślę, że masz rację, stwierdzając, że testy jednostkowe naprawdę pokazują ich wartość, gdy wymagane są modyfikacje.

Ewan
źródło
2
Hej, piszę samodokumentujący się kod! Moje klasy mają jedną odpowiedzialność i dlatego są łatwe do zrozumienia. Nikt nie będzie musiał mnie ścigać :)
MetaFight
7
@MetaFight, a jeśli tak, to łatwo będzie je znaleźć na żywym złotym jednorożcu!
jonrsharpe
3
Nazywam go Goldicorn.
MetaFight,
Mówiąc poważniej, tak, masz rację. Rozważyłem rejestrowanie historii „testowania długów”, aby móc spłacić część środków, gdy moje obciążenie pracą będzie mniejsze.
MetaFight,
4
Jeśli kod jest napisany dobrze, ale zawiera błąd, prawdopodobnie łatwo będzie zrozumieć, co pierwotny programista zamierzał osiągnąć, czytając kod, a nowy programista może dodać niezbędne testy. Jedynym problemem jest to, że większość programistów uważa, że ​​piszą dobry kod. „Dobry” zależy w dużej mierze od twojej perspektywy i doświadczenia jako programisty. Jest w tym napięcie, którym trzeba zarządzać.
Phil
4

Zgadzam się zarówno z Danielem Hollinrake'em, jak i Ewanem, że pierwszym kluczowym punktem, dlaczego Twoja modyfikacja „tylko jeśli testujesz” działa dobrze, jest:

I am the sole developer on my projects and I am responsible for everything

i że prawdopodobnym drugim kluczowym punktem jest:

you're producing nice clean code

Nie sądzę, że TDD zapewnia ogromny wzrost produktywności dla samotnych programistów i może nie poprawić jakości twojego kodu, jeśli już piszesz dobry, czysty kod.

Jednak TDD z pewnością poprawi jakość kodu słabych / niedoświadczonych / przestarzałych programistów, szczególnie gdy przyjdzie czas na modyfikację kodu bez niszczenia czegokolwiek innego. Co więcej, jeśli osoba modyfikująca kod nie jest tą samą osobą, która napisała kod pierwotnie lub upłynęło kilka miesięcy.

Innymi słowy, myślę, że TDD jest zarówno dobrą praktyką do poprawy jakości twojego kodu (jak się przyznajesz), ale także (i co ważniejsze) rodzajem zabezpieczenia, gdy pracujesz z przeciętnymi lub przeciętnymi programistami (powiedzmy, z innego dział lub inna firma), co jest znacznie częstszą sytuacją niż praca solo.

sergut
źródło
1
Myślę, że część problemu polega na tym, że może być tylko jeden programista, ale baza kodu często rośnie z czasem, a to, co działało (do testowania), gdy było małe, nie działa, gdy się powiększa.
Michael Durrant
3

Dla mnie kluczową rzeczą wydaje się być to:

Jestem jedynym programistą w moich projektach i jestem odpowiedzialny za wszystko: zbieranie wymagań, projektowanie, architekturę, testowanie, wdrażanie itp. Podejrzewam, że właśnie dlatego mój proces działa.

To działa dla ciebie i tworzysz ładny, czysty kod (zakładam!). Jedyne, co powiedziałbym, że musisz zrobić, to stworzyć uprząż testową, aby inni programiści mogli wejść i mieć pewność wprowadzania zmian. Również uprząż testowa zapewnia spójność działania kodu.

Myślę, że twoje podejście jest podobne do mojego. Zwykle jestem jedynym programistą w moich projektach. Przekonałem się, że docenienie TDD umożliwiło mi pisanie mniejszych funkcji i czystszego kodu, ale dodaję testy, pisząc kod jako test uprzęży. W ten sposób, gdy kod ewoluuje i zmienia się funkcjonalność, mogę być całkiem pewny, że wprowadzam zmiany.

Drugim powodem pisania testów jest to, że uważam, że są one formą dokumentacji. Mogą wyjaśnić moje rozumowanie, dlaczego powstała funkcja. Ale tutaj myślę więcej o rozwoju opartym na zachowaniach.

Daniel Hollinrake
źródło
Powiedziałbym, że pakiet testowy przyszedłby na 4 miejscu, aby przekazać innym programistom - dokument wymagań, diagramy architektury i dokumenty projektowe byłyby o wiele ważniejsze w komunikowaniu spraw niż kilka testów jednostkowych.
gbjbaanb
To słuszna kwestia, ale niestety z mojego doświadczenia wynika, że ​​prawie każdy projekt, nad którym pracowałem nad dokumentacją, jeśli istnieje, jest nieaktualny lub niekompletny.
Daniel Hollinrake,
1
To samo tutaj, dlatego deweloperzy powinni zdawać sobie sprawę ze znaczenia dokumentowania rzeczy i nie pisania więcej kodu w formie testów! Może potrzebujemy narzędzi, które pozwolą na lepsze generowanie dokumentacji (tj. Nie jest to tylko formatowanie podpisów metod) na podstawie komentarzy do kodu i zgłoszeń wymagań.
gbjbaanb
Trochę zredagowałem swoją odpowiedź w odpowiedzi na twoje komentarze. Dziękuję Ci.
Daniel Hollinrake,
1
@gbjbaanb Jeśli mogę pomóc, lubię unikać pisania dokumentacji wymagań, schematów architektury i dokumentacji projektowej. Jest tak, ponieważ mają tendencję do starzenia się bardzo szybko. W moim przypadku mam szczęście, ponieważ zarządzam wieloma małymi aplikacjami przy bardzo niewielkiej liczbie obowiązków. To sprawia, że ​​wymagania i dokumentacja architektury są nieco przesadzone. A projekty są na tyle małe, że ogólny projekt jest jasny. Co ja jestem dokumentowania jest jednak to, w jaki sposób systemy interakcji, jak je wdrożyć, i jak monitorować ich zdrowie.
MetaFight
3

Testowanie jednostkowe polega na rozwiązaniu problemu utrzymania kodu. Chociaż są ludzie, którzy twierdzą, że szybciej piszą kod z TDD niż bez niego, nie jestem zaskoczony, że możesz napisać więcej nowego kodu bez pisania testów.

Problemy, które widzę podczas pisania testów tuż przed ich zmianą:

Często muszę szybko wprowadzać zmiany

Możesz ogólnie zaoszczędzić czas, pisząc testy tylko wtedy, gdy ich potrzebujesz, ale nie cały czas jest równy. Spędzanie 2 godzin pisania testów, aby zaoszczędzić 1 godzinę, gdy jestem w trybie kryzysowym - całkowicie tego warte.

Łatwiej jest pisać testy w tym samym czasie, w którym piszę kod

Aby poprawnie napisać testy jednostkowe, musisz zrozumieć kod, który testuję. Często używam testowania jednostkowego jako ćwiczenia w zrozumieniu, ale testowanie jednostkowe istniejącego kodu może być czasochłonne, ponieważ zrozumienie istniejącego kodu jest czasochłonne. Porównaj to z pisaniem testów podczas pisania kodu, a znajdziesz go znacznie szybciej, ponieważ już rozumiesz kod - właśnie go napisałeś!


Definicja starszego kodu autorstwa Michaela Feathersa to kod bez testów. Bez względu na to, czy zgadzasz się z jego definicją, jasne jest, że znaczna część kosztów modyfikacji istniejącego kodu zapewnia upewnienie się, że nadal działa zgodnie z oczekiwaniami, często nawet nie jest jasne, jakie jest oczekiwane zachowanie.

Pisanie testów jednostkowych kompensuje koszty, kodując zrozumienie prawidłowego zachowania, a także zapewniając „przyszłemu nam” łatwy sposób sprawdzenia, czy zachowanie jest prawidłowe.

Justin
źródło
2

To dobre pytanie, a FWIW wrzucę moje dwa centy.

Około rok temu programowałem w Salesforce, platformie, która miała wbudowany mechanizm, który zmusił cię do niekoniecznego pisania testów przed napisaniem kodu , ale zmusił cię do pisania testów w ogóle.

Sposób, w jaki działał, polegał na tym, że system zmusiłby cię do napisania testów i dokonałby obliczenia liczby linii twojego kodu, które zostały przetestowane w procentach. Jeśli cały kod w całej instancji produkcyjnej spadł poniżej 75% przetestowanych. Salesforce nie działa.

W rezultacie za każdym razem, gdy robiłeś coś w Salesforce, musiałeś pisać lub aktualizować testy. Chociaż jestem pewien, że ma to ogromny wpływ na udział w rynku Salesforce, pod względem życia dewelopera był to ogromny ból w dupie .

Często próbujesz przejść przez mały bilet, a potem pojawia się testowanie i podwaja czas programowania, dla funkcji, o której wiesz, że działa.

Potem niezręczna koncepcja TDD przeszła przez nasz dział aż do naszych baz danych. Nasi architekci chcieli przeprowadzić dokładne testy w każdym aspekcie naszego działu IT. Lekki ból w tyłku, spotkać jeszcze większy ból w tyłku.

Wtedy TDD nigdy nie miało dla mnie sensu, a nawet teraz tak nie jest. Wiele funkcji, które napisałem w mojej obecnej roli, odbywa się w mechanizmie podobnym do tego, o którym wspominałeś: w pionowych plasterkach, które dopracowuję, aż zadziałają. Kiedy pełniłem tę starą rolę i nadal często nie wiem, co zrobi mój kod, dopóki go nie napiszę , więc pomysł, żebym mógł napisać testy w celu uruchomienia kodu, właśnie zamierzam napisać. nie ma dla mnie sensu, jest nieporęczna i przede wszystkim strata czasu.

To powiedziawszy, testy są cudownymi i magicznymi rzeczami, które sprawiają, że wszystko jest na świecie . Sprawiają, że kod jest poprawny, zapewniają, że Twoja aplikacja robi to, co myślisz, i ogólnie wszystko jest płynniejsze. Pytanie nie brzmi zatem, czy piszesz testy przed kodowaniem, czy po nim. Pytanie, ile czasu poświęcisz na testowanie. To prawdziwy problem, przynajmniej w moim doświadczeniu w tworzeniu oprogramowania. Testowanie wymaga czasu i pieniędzy, a Ty musisz to robić w ramach sprzecznych interesów.

Tak więc ogólnie zgadzam się z tobą: TDD w praktyce jest nieco niewygodne i kłopotliwe. W tym momencie musisz pamiętać, co działa najlepiej w Twojej obecnej sytuacji . Jeśli piszesz krytyczny kod, po prostu upewnij się, że jest ogólnie testowany. Jeśli masz czas, spróbuj TDD i sprawdź, czy to coś w tym procesie doda.

Koder kanadyjski
źródło
2
Wydaje mi się, że dzieli nas jedno pokolenie języków od poprawnego rozwiązania TDD. Myślę, że obecnie TDD jest w pewnym sensie „przymocowane” do większości języków dzięki frameworkowi xUnit. W pewnym momencie zostanie po prostu wbudowane w sposób, w jaki odbywa się kodowanie - a nie osobno. Tak jakbyś zdefiniował klasę, natychmiast wygenerowane zostaną kody pośredniczące dla wszystkich testów, wraz z pewnym podzbiorem samych testów (tych, które można łatwo określić za pomocą samych klas / metod).
Calphool,
3
@Calphool Mamy już właściwie zintegrowany łatwo sprawdzalne kilka rzeczy na język! Nazywamy to pisaniem statycznym . Rust idzie o krok dalej, sprawdzając pożyczki, aby sprawdzić, czy jest jeszcze więcej błędów. Ale większość testów jest specyficzna dla tej właśnie klasy („jeśli kliknę przycisk, widget zmieni kolor na czerwony”) - skąd kompilator / IDE może wiedzieć, że zamierzasz to przetestować?
user253751
1
@immibis: Być może poprzez dalsze rozszerzenie sprawdzania typu. Być może pojęcie „widget zmienia kolor na czerwony” staje się pojęciem pierwszej klasy, które można w jakiś sposób wywnioskować z kodu. Nie twierdzę, że mam odpowiedzi, po prostu czuję, że TDD jest wciąż na tyle nowy, że nie został w pełni zintegrowany z ewolucją języka.
Calphool,
1
Salesforce specjalnie źle wszystko testuje: wymagają przeprowadzenia testów, ale bardzo trudno jest napisać testy jakości . Brzmi świetnie w teorii, ale w praktyce sprawia, że ​​programiści chcą oderwać oczy łyżkami.
1

Nie mogłem polecić twojego podejścia.

Jeśli zastosuję twoje podejście, będzie to na przykład następujące (dom to aplikacja):

  1. Zaczynam budować dom dla mojej rodziny jako murarz z pewną wiedzą lub jako początkujący.
  2. Znam wymagania, takie jak pokoje dziecięce, pokoje gościnne i zaczynam budować mój „prototypowy” dom.
  3. Kilka razy później twój „prototypowy” dom jest już gotowy.
  4. Zaczynam sprawdzać, czy struktura jest wystarczająco stabilna ręcznie. Zbieram więc ciężary i przenoszę je do różnych pomieszczeń na pierwszym piętrze. Aby mieć pewność, że kiedy siedzę w pokoju z rodziną, sufit nie pęka. Ale pęka i zaczynam refaktoryzować. Najpierw oczyść całą masę. Następnie zbuduj nowy i przetestuj go ponownie ręcznie, aż będzie wystarczająco stabilny.
  5. Następnie przeprowadzam się z rodziną. Wszystko w porządku.
  6. Ćma później odwiedzają nas moi kuzyni i rodzice. Ale zanim wejdą do naszego domu, muszą zapłacić architektowi i inżynierom budownictwa, aby upewnić się, że sufit nie pęknie, gdy będziemy siedzieć w jednym z pokoi na pierwszym piętrze.
  7. Architekt i inżynier budownictwa mają dużo pracy, ponieważ nie mają z czego zacząć. Muszą więc wejść do mojego domu i zobaczyć, jak go zbuduję.
  8. I znowu nie jest wystarczająco stabilny. Muszą więc zmienić grunt na pierwszym piętrze.
  9. Ale potem wszystko jest w porządku i wszyscy mogą bezpiecznie wejść do mojego domu.

Więc twoje podejście kosztuje dużo czasu i dużo wiedzy, zanim zbuduję dom z twoim podejściem. Lub zajmuje to trochę czasu! Nie jest też dość Dżentelmenem pozwalanie innym testom na pisanie kodu, gdy zmienią się wymagania.

Istnieje więc lepsze podejście bez programowania „prototypu” i rozpoczynania refaktoryzacji. Zamiast programować prototyp „zrób projekt z UML swojej aplikacji w następujący sposób.

  1. Utwórz diagram UseCase. Możesz użyć draw.io na początek.
  2. Następnie utwórz diagram EPK na podstawie swoich przypadków użycia, aby określić zachowanie. (ZACHOWANIE aplikacji) Szybsze refaktoryzacja niż refaktoryzacja zakodowanego prototypu. Zwłaszcza gdy jesteś początkującym.
  3. Utwórz diagram klasowy. (STRUKTURA Twojej aplikacji)
  4. Określ, gdzie możesz mieć problemy z implementacją zachowania.
  5. Napisz prosty prototyp z 10 lub 20 liniami kodu, aby ustalić, jak możesz zaimplementować to zachowanie. Dobre dla początkującego. Lub obejrzyj samouczek, zapoznaj się z kodem źródłowym innych przykładowych aplikacji. Jak to rozwiązali.
  6. Następnie zacznij kodować. Przetestuj pomyślnie testy UseCase. Można to zrobić na różne sposoby. Najpierw utwórz całą Strukturę, która jest potrzebna do testu i ten UseCase. Podczas korzystania z Enterprise Architekt można wygenerować strukturę. Na podstawie twoich diagramów. Lub utwórz strukturę podczas okablowania testu. Dlatego nie pojawiają się błędy kompilacji. Wspomnij tutaj, że TYLKO musisz przetestować ZACHOWANIE swojej aplikacji. Przypadki użytkowania, które masz.
  7. Następnie zaimplementuj zachowanie swojego UseCase.
  8. Po udanym UseCases zacznij pisać Testy dla wyjątków. I zawsze dobrze jest widzieć zielone kolory, gdy wasze testy są ważne;)
  9. I gotowe.

Jasne, że takie podejście wymaga również wiedzy w języku UML, ale szybko się uczy. Zmiana nazwy klasy lub poruszanie strzałkami w digramie jest zawsze szybsze niż w IDE. Ale nauka korzystania z ram testowych będzie na początku bardziej wyczerpująca. Najlepszy jest tutaj, aby spojrzeć uruchomić test projektów open source i zobaczyć, jak działają. Ale kiedy masz aplikację testową, następna aplikacja będzie znacznie szybsza. Myślę, że dobrze jest wiedzieć, że wszystko działa dobrze.

Po prostu przegłosowałem te podejścia, ponieważ są one bardzo czasochłonne dla początkujących i wcale nie są dobre. Aby mieć czyste granice między strukturą a zachowaniem, możesz użyć Projektu opartego na Domenie i w sekcji Rozmieść samą domenę za pomocą dwóch pakietów (jeden pakiet o nazwie struktura i drugi nazwany zachowanie). Również dla twoich testów. prosty przykład sprawdź ten przykład napisany w języku Java.

Skały360
źródło
1

Kod, który piszę, działa. Działa, ponieważ testuję to ręcznie.

Czy przetestowałeś ręcznie każdą możliwą gałąź twoich warunków po niewielkiej zmianie? Jak długo trwa pętla sprzężenia zwrotnego podczas ręcznego testowania. Jak blisko jest do pętli sprzężenia zwrotnego z automatycznymi testami.

Zautomatyzowane testy (bez względu na to, czy przeprowadzane są testy w pierwszej kolejności, czy nie), przyspieszają - zapewniając szybszą pętlę zwrotną w kodzie.

Czy na pewno pamiętasz, aby przetestować jakiś warunek ręcznie po sześciu miesiącach - nie mów, że udokumentujesz wszystkie ważne warunki do przetestowania - ponieważ pisanie dokumentacji / komentarza jest równoznaczne z pisaniem testu (dokumentacja wykonywalna)

  • Wybierz pionowy kawałek pracy

  • Opracuj działający prototyp

  • Refaktoryzuj, aż wszystko będzie ładne i uporządkowane

I znowu: czy podczas refaktoryzacji ręcznie przetestowałeś całą logikę, na którą wpływa refaktoryzacja? Ile czasu zajmuje testowanie zmiany refaktoryzacji? Jeśli refaktoryzacja zepsuje jakiś kod, ile czasu zajmie znalezienie przyczyny przerwania?

  • Usiądź i doceń pięknie napisany przeze mnie SOLIDNY ​​i testowalny kod.

Piękny i czysty kod, którym się podobałeś, jest bardzo subiektywny. Twój kod może być dla Ciebie czysty i rozsądny. Najlepszą metodą sprawdzenia, czy Twój kod jest naprawdę czytelny, zrozumiały i testowalny, to testy i recenzje kodu wykonane przez innych programistów.

Twoja droga okazała się bardzo produktywna tylko dlatego, że jesteś programistą pracującym tylko z kodem, i myślę, że dopiero zaczynasz pracę w tym projekcie (Ile lat pracujesz nad tym projektem? 6-8 miesięcy?).
Nadal pamiętasz wszystko, co napisałeś, i możesz rozpoznać przyczynę możliwych problemów. Jestem pewien, że zaczniesz pisać testy od 2-3 lat projektu - ponieważ chcesz mieć pewność, że niczego nie zapomnisz.

Fabio
źródło
0

Jeśli nigdy nie popełniasz błędów, tak naprawdę nie potrzebujesz testów. Większość programistów popełnia błędy, ale jeśli nigdy tego nie zrobisz i jesteś pewien, że nigdy nie popełnisz błędów w przyszłości (a ty jesteś jedynym w projekcie), naprawdę nie ma powodu, aby marnować czas na pisanie testów.

Ale twoje rozwiązanie jest w połowie drogi, ponieważ proponujesz pisanie testów przy zmianie kodu, ale jednocześnie twoja metoda zakłada, że ​​nigdy nie popełnisz błędów, decydując, dla których części kodu napisać testy. Działa to tylko wtedy, gdy zawsze doskonale rozumiesz, na które obszary może mieć wpływ zmiana. Myślę, że wielu zwykłych programistów (oczywiście nie ty!) Doświadczyło zmiany, a następnie test gdzieś nieoczekiwanie kończy się niepowodzeniem, ponieważ popełniłeś błąd.

Oczywiście dobra architektura, zasady SOLID itp. Powinny temu zapobiec, ale większość programistów nie jest doskonała i dlatego testy w całym systemie są cenne.

JacquesB
źródło
Oczywiście dobra architektura, zasady SOLID itp. Powinny temu zapobiec - nie. Złożone systemy mają części, które wpływają na inne części, tak właśnie jest. np. modyfikacja gramatyki Antlr w Rubberduck może łatwo sprawić, że zamierzona zmodyfikowana część będzie działała idealnie, jednocześnie niszcząc 45 innych funkcji. Bez dokładnych testów nie ma sposobu, aby się dowiedzieć, i musisz być szalony, aby za każdym razem ręcznie testować wszystkie przypadki. Jeśli zmienię coś w resolwerze i zepsuje się 987 testów, wiem, że zrobiłem coś złego i na co to wpłynęło.
Mathieu Guindon