Mówiąc w kategoriach codziennych, praktycznych, myślę, że to całkowicie zależy od kontekstu .
W med-dużym zespole, pracującym zgodnie z wysokimi / bardzo wysokimi standardami (systemy bankowe, wojskowe, na dużą skalę, z wysokim budżetem lub systemami o krytycznym znaczeniu dla biznesu), myślę, że wyraźnie „debugowanie” powinno być „wynikiem testów” i są wyraźnie bardzo różne rzeczy . Idealnie testowanie prowadzi do debugowania (w środowisku testowym), a podczas produkcji potrzebujemy prawie zerowego z nich.
Testy mają szeroki zakres, są regularne i bardzo sformalizowane - podczas gdy debugowanie jest szczególnym procesem, który zdarza się czasami, gdy zachodzi potrzeba naprawienia określonej awarii - co nie jest oczywiste i wymaga głębszego badania funkcjonowania systemu i wynikowych wyników.
Tutaj moim zdaniem testowanie jest czymś niezbędnym, podczas gdy debugowanie jest specyficznym narzędziem potrzebnym tylko wtedy, gdy rozwiązanie problemu jest nieprzejrzyste.
Całkowicie rozumiem oczywistą użyteczność TDD dla dużych zespołów i systemów, niż po prostu nie stać mnie na buggy. Ma to również sens w przypadku złożonych (często „back-endowych”) systemów lub jeśli w kodzie występuje wysoki stopień złożoności w porównaniu do danych wyjściowych. Wtedy „testowanie” ma realistyczną szansę na poinformowanie, kiedy i dlaczego wystąpią awarie. Systemy, które wykonują wiele skomplikowanych prac i / lub dają wyraźnie mierzalne wyniki, są na ogół łatwe do przetestowania, dlatego testowanie różni się od debugowania. W takich przypadkach testowanie silnie implikuje opartą na procedurze, sformalizowaną metodę potwierdzania lub odrzucania dopasowania oczekiwań i rzeczywistych wyników. Testowanie odbywa się cały czas i czasami informuje nas o potrzebie debugowania.
Byłoby cudownie, gdyby była to wszechobecna prawda, bardzo bym chciał, gdyby moje cykle programistyczne były ograniczone przez jasno określone wyjście binarne (czerwony, zielony), ale ...
W moim przypadku (co jest zresztą szczególne - praca w 98% solo na niedużych, niedofinansowanych internetowych systemach administracyjnych zorientowanych na dane) po prostu naprawdę nie widzę, jak TDD może mi pomóc. A raczej „debugowanie” i „testowanie” są praktycznie takie same.
Głównie jednak użycie terminu „testowanie” implikuje / ściśle wiąże się z metodologią TDD.
Wiem, że jest to całkowicie, całkowicie bez Zeitgeist „unikaj niewierzącego, unikaj, unikaj”, godne pogardy rzeczy do powiedzenia. Ale myśląc o moim kontekście, z praktycznym kapeluszem, po prostu nawet nie jestem niejasny, w mojej najdzikszej wyobraźni widzę, jak TDD może pomóc mi w dostarczeniu większej wartości do moich klientów.
A raczej zdecydowanie nie zgadzam się z powszechnym założeniem, że „testowanie” jest procesem opartym na formalnym kodzie.
Moje podstawowe zastrzeżenie (mające zastosowanie w moim szczególnym * kontekście *) polega na tym, że ...
Jeśli nie mogę napisać kodu, który działa niezawodnie - to do diabła, że mam napisać kod, który działa niezawodnie, aby przetestować ten przypuszczalnie nietypowy kod.
Dla mnie nigdy nie widziałem żadnego przykładu ani argumentu, który (w moim szczególnym kontekście) zachęciłby mnie na tyle, żebym nawet niepokoił się myślami o napisaniu pojedynczego testu , mógłbym teraz napisać jakiś śmiesznie nieistotny kod testowy, może „czy moje repozytorium zwraca użytkownika encja o nazwie == X, kiedy proszę o to dokładnie - i tylko to -? ale prawdopodobnie jest we mnie więcej użyteczności, pisząc ten streaming, może-internet-naprawdę-jest-po prostu-głupi-wytrysku- samozadowolenie - dziko niedoinformowany - gotujący się we krwi szef - marnotrawnie głupiutki śmieć, ale po prostu czuję potrzebę odgrywania tu roli adwokata diabła. (Mam nadzieję, że ktoś pokaże mi światło i nawróci mnie, może to da moim klientom lepszy stosunek jakości do ceny?).
Prawdopodobnie „debugowanie” czasami jest tym samym co „testowanie”. Rozumiem przez to, że w codziennym życiu zawodowym spędzam co najmniej jedną trzecią mojego czasu, grając z lokalną wersją mojego systemu w różnych przeglądarkach, desperacko próbując różnych różnych zwariowanych rzeczy, próbując przerwać moją pracę, a następnie badając powody, dla których zawiodło i ich poprawienie.
W 100% zgadzam się z oczywistą użytecznością w mantrze TDD „czerwony / zielony / refaktor”, ale dla mnie (pracując w niskim budżecie, solo Dev RIA land) naprawdę bardzo chciałbym, aby ktoś pokazał mi, jak mógłbym być może , logicznie i niezwykle realistycznie, uzyskam jakąkolwiek dodatkową wartość, pisząc więcej ( tak jak potencjalnie wadliwy kod testowy) niż ja faktycznie wchodzę w interakcję z pełnym (i zasadniczo tylko) efektem moich wysiłków, które są zasadniczo związane z prawdziwą ludzką interakcją.
Dla mnie, gdy programiści mówią o „testowaniu”, zwykle oznacza to TDD.
Staram się kodować tak, jakby istniały testy, myślę, że wszystkie wzorce / praktyki i trendy, do których zachęcał cały ten rozwój skoncentrowany na testowaniu, są fantastyczne i piękne, ale dla mnie w moim małym świecie „testowanie” nie polega na pisaniu większej ilości kodu, a tak naprawdę testowanie realnego świata generuje go w zbliżający się realistyczny sposób, i to jest właściwie to samo co debugowanie, a raczej aktywną zmianą jest tutaj „debugowanie”, które jest bezpośrednim rezultatem niezautomatyzowanych „testowania” zorientowanych na człowieka. Jest to sprzeczne z ogólnie przyjętym poglądem na „testowanie” jako coś zautomatyzowanego i formalnego oraz „debugowanie” jako coś ludzkiego i doraźnego lub nieustrukturyzowanego.
Jeśli celem jest naprawdę stosunek jakości do ceny / wysiłku, a tworzysz interaktywne aplikacje internetowe, to wynikiem wysiłku są strony internetowe i bardzo zasadniczo ich reakcja na wkład człowieka - więc „testowanie” najlepiej osiągnąć przez testowanie te strony internetowe poprzez rzeczywistą interakcję człowieka. Gdy ta interakcja prowadzi do nieoczekiwanych lub niepożądanych wyników, następuje „debugowanie”. Debugowanie jest również ściśle związane z ideą kontroli stanu programu w czasie rzeczywistym. Testowanie jest ogólnie związane z automatyzacją, co moim zdaniem jest często niefortunnym skojarzeniem.
Jeśli celem jest naprawdę wartość wysiłku, a automatyczne testowanie jest wydajne i bardzo korzystne, podczas gdy debugowanie jest albo wynikiem tych testów, albo słabym zamiennikiem automatycznych testów, to dlaczego jest drugą najczęściej odwiedzaną witryną na świecie (Facebook ) tak często wypełnione oślepiająco oczywistymi (dla użytkowników, ale wyraźnie nie zespołem testującym i kodem testującym) błędami?
Może dlatego, że koncentrują się na uspokajających zielonych światłach i zapominają o faktycznym wykorzystaniu wyników swojej pracy?
Czy zbyt wielu programistów uważa, że testowanie to coś, co robisz z kodem, a debugowanie to coś, co robisz od czasu do czasu z IDE, ponieważ ikona zmienia kolor na czerwony i nie możesz zrozumieć, dlaczego? Sądzę, że słowa te wiążą się z niefortunnymi ocenami wartości, które na ogół zaciemniają praktyczną rzeczywistość tego, na czym powinniśmy się skupić, aby wypełnić luki między oczekiwaniami a wynikami.