Parlando in termini quotidiani e pratici, penso che dipenda totalmente dal contesto .
In un team di grandi dimensioni, lavorando a standard elevati / molto elevati (pensa a sistemi bancari, militari, su larga scala, a budget elevato o sistemi di business critical), penso che chiaramente il "debugging" dovrebbe essere "un risultato di test" , e sono chiaramente cose molto diverse . Idealmente il test porta al debug (in un ambiente di gestione temporanea) e in produzione abbiamo bisogno di quasi zero di uno dei due.
I test sono di ampia portata, regolari e molto formalizzati - mentre il debug è un processo particolare che si verifica occasionalmente quando è necessario correggere un determinato errore - che non è ovvio e richiede un'analisi più approfondita del funzionamento di un sistema e dei risultati risultanti.
Qui nella mia mente il testing è qualcosa di essenziale, mentre il debug è uno strumento specifico necessario solo quando la risoluzione di un errore è opaca.
Capisco perfettamente l' ovvia utilità in TDD per grandi team e / o sistemi che semplicemente non possono permettersi di essere "buggy". Inoltre ha chiaramente molto senso per sistemi complessi (spesso "back-end") o se esiste un'alta percentuale di complessità nel codice rispetto all'output. Quindi il "test" ha una possibilità realistica di informare quando e perché si verificano guasti. I sistemi che svolgono molte attività complesse e che generano output chiaramente misurabili sono generalmente facilmente testabili, pertanto i test sono distinti dal debug. In questi casi, il testing implica fortemente un metodo formalizzato e basato sulla procedura per confermare o confermare la corrispondenza tra aspettative e risultati effettivi. I test vengono eseguiti continuamente e occasionalmente ci informano della necessità di eseguire il debug.
Sarebbe bello se questa fosse una verità onnipresente, mi piacerebbe che i miei cicli di sviluppo fossero delimitati da un output binario chiaramente definito (rosso, verde) ma ...
Nel mio caso (che è certamente particolare - lavorando da solo al 98% su sistemi di amministrazione aziendale focalizzati sui dati di piccole e medie dimensioni, basati sul web e poco finanziati), non riesco proprio a vedere come TDD possa eventualmente aiutarmi. O meglio "debugging" e "testing" sono praticamente gli stessi.
Principalmente sebbene l'uso del termine "test" implichi / sia strettamente correlato alla metodologia del TDD.
So che questa è una cosa totalmente, assolutamente non Zeitgeist, "evitare il non credente, evitare, evitare", cosa spiacevolmente non fredda da dire. Ma pensando al mio contesto, con un cappello pratico sopra, non lo faccio nemmeno vagamente, nella mia immaginazione più sfrenata vedo come TDD potrebbe eventualmente aiutarmi a fornire più valore in denaro ai miei clienti.
O meglio, non sono assolutamente d'accordo con l'ipotesi comune che il "testing" sia un processo formale basato su codice.
La mia obiezione di base (applicabile nel mio particolare * contesto *) è che ...
Se non riesco a scrivere un codice che funzioni in modo affidabile, allora come diavolo dovrei scrivere un codice che funzioni in modo affidabile per testare il presumibilmente sotto codice standard.
Per me non ho mai visto alcun esempio o argomento che (nel mio particolare contesto) mi ha entusiasmato abbastanza da disturbarmi a pensare di scrivere un singolo test , potrei scrivere un codice di test ridicolmente inconsistente in questo momento, forse "il mio repository restituisce un utente entità con Nome == X, quando lo chiedo esattamente - e solo - quello? ", ma probabilmente c'è più utilità in me che scrivo questo streaming, forse-the-internet-real-is-just-pure-foolish-spouting- spazzatura auto-gratificante-selvaggiamente-sotto-informata-bollente-bollente-sprecamente-sciocca, ma sento solo il bisogno di recitare qui l'avvocato del diavolo. (Spero che qualcuno mi mostri la luce e mi converta, forse questo finirà per dare ai miei clienti un miglior rapporto qualità-prezzo?).
Probabilmente il "debug" a volte è lo stesso del "testing". Con questo intendo davvero che nella mia vita lavorativa quotidiana trascorro almeno un terzo del mio tempo a giocare con la versione locale del mio sistema in diversi browser, cercando disperatamente varie cose stravaganti nel tentativo di interrompere il mio lavoro e quindi indagare i motivi per cui ha fallito e correggerli.
Concordo al 100% con l'ovvia utilità nel mantra TDD "rosso / verde / refactor", ma per me (lavorando con budget basso, terra di sviluppo personale RIA) mi piacerebbe davvero che qualcuno mi mostrasse come potevo possibilmente , logicamente e in modo realistico realisticamente ottenere qualsiasi valore aggiuntivo dalla scrittura di più ( proprio come codice di test potenzialmente imperfetto ) di quello che faccio dall'interazione effettiva con l'output completo (ed essenzialmente solo) dei miei sforzi che sono essenzialmente legati alla vera interazione umana.
Per me quando gli sviluppatori parlano di "test", in genere implica TDD.
Provo a programmare come se ci fossero test, penso che tutti i modelli / pratiche e tendenze che tutti questi test incentrati sullo sviluppo hanno incoraggiato siano fantastici e belli, ma per me nel mio piccolo mondo "test" non sta scrivendo più codice, è in realtà testare il mondo reale lo produce in modo realistico e si avvicina allo stesso modo del debug, o piuttosto il cambiamento attivo qui è il "debug" che è il risultato diretto di "test" umani non incentrati sull'output. Ciò è in contrasto con la visione generalmente accettata di "test" come qualcosa di automatizzato e formale e di "debug" come qualcosa di umano e ad hoc o non strutturato.
Se l'obiettivo è davvero un rapporto qualità / prezzo e stai realizzando applicazioni interattive basate sul web, l'output dello sforzo sono le pagine Web e in sostanza il modo in cui reagiscono all'input umano , quindi il "test" è meglio ottenuto testando quelle pagine web, attraverso una vera interazione umana. Quando questa interazione porta a output imprevisti o indesiderati, si verifica il "debug". Il debug è inoltre strettamente correlato all'idea di ispezione in tempo reale dello stato del programma. I test sono generalmente associati all'automazione che penso sia spesso un'associazione sfortunata.
Se l'obiettivo è davvero un valore per lo sforzo e i test automatizzati sono efficienti e altamente vantaggiosi, mentre il debug è solo un risultato di tali test o un sostituto scadente per i test automatizzati, allora perché è il secondo sito Web più visitato al mondo (Facebook ) così spesso pieno di bug palesemente ovvi (per gli utenti, ma chiaramente non per il team di test e il codice di test)?
Forse è perché si stanno concentrando sulle rassicuranti luci verdi e si stanno dimenticando di utilizzare effettivamente i risultati del loro lavoro?
Troppi sviluppatori pensano che il testing sia qualcosa che fai con il codice e il debugging è qualcosa che fai occasionalmente con l'IDE perché un'icona diventa rossa e non riesci a capire perché? Penso che queste parole abbiano giudizi di valore sfortunati associati ad esse, che generalmente oscurano la realtà pratica di ciò su cui dovremmo concentrarci per colmare le lacune tra aspettative e risultati.