Come migliorare testare il tuo codice [chiuso]

12

Oggi ho controllato una modifica di un codice che non funzionava affatto a causa di qualcosa di piuttosto stupido ma molto cruciale. Mi sento davvero male e spero di aver finalmente imparato qualcosa da esso. La cosa stupida è che ho già fatto queste cose prima e mi dico sempre, la prossima volta non sarò così stupido ... Poi succede di nuovo e mi sento ancora peggio.

So che dovresti tenere il mento in alto e imparare dai tuoi errori, ma ecco la cosa: cerco di migliorare me stesso, semplicemente non vedo come posso impedire che queste cose accadano.

Quindi, ora ti sto chiedendo ragazzi: avete certe regole di base quando testate il vostro codice?

    
posta Peter 16.02.2011 - 12:49
fonte

6 risposte

17

Scrivi test prima di apportare modifiche al codice.

Se la tua modifica proposta è quella di correggere un bug, fai fallire il test in un primo momento dimostrando il bug. Quindi assicurati che passi dopo aver corretto il bug. Se scrivi il test in seguito e lo hai visto solo dopo averlo superato, non puoi essere sicuro che abbia testato correttamente il bug in primo luogo.

Se la modifica proposta consiste nel modificare la funzionalità esistente o aggiungere una funzione, scrivere alcuni test per garantire una buona copertura dell'area del codice che si sta modificando. Assicurati che questi test passino prima di iniziare a cambiare codice e, al termine, passaci ancora.

    
risposta data 16.02.2011 - 12:56
fonte
3

Non dimenticare di testare i casi limite! Un sacco di bug sono perché l'azione più comune è stata testata, ma non i meno comuni.

    
risposta data 16.02.2011 - 17:19
fonte
2

Segui i consigli tecnici nelle risposte tecnicamente orientate; è roba buona. La mia risposta è più sull'atteggiamento.

Sentirsi male nel rendere il tipo di errore che ogni sviluppatore fa occasionalmente è semplicemente assurdo, e non ti aiuta a non commettere questo tipo di errore in futuro. Mentre ti siedi lì sentendosi male, la costruzione è ancora rotta, sai? E poi il tuo lavoro consiste nell'evitare errori, che so fare alzarsi dal letto al mattino un'entusiasmante avventura ogni giorno, giusto?

Ho sentito di aziende in cui il check-in di codice non funzionante è causa di vergogna pubblica. Non riesco nemmeno a capire il tipo di pensiero deformato, frat-boy, di livello medio-alto che porterebbe a un simile comportamento. Difficilmente potrebbe esserci QUALCHE COSA più controproducente per un capo squadra o un dirigente.

Quindi non abbatterti. L'abbiamo fatto tutti. Probabilmente mi sono costato mezza giornata a settimana con errori stupidi, e lo sto facendo da molto tempo. Questo è quello che sembra scrivere codice - stai costantemente attaccando ciò che sembra essere la tua inadeguatezza. Ciò che rende un professionista un professionista non è una qualità mitica di non aver mai commesso errori (compresi quelli grandi a volte), ma come si rispetti agli errori che fanno.

Se c'è un solo mantra che potrei instillare in ogni sviluppatore con cui lavoro, è questo: Non sei il tuo codice . Scrivi il codice. Lo scrivi così bene ed efficacemente. Poi vai a casa. Se equiparai il tuo valore o la tua autostima a una persona con la qualità del tuo codice, ti manca solo la barca per sapere chi sei veramente.

    
risposta data 16.02.2011 - 15:43
fonte
2

Un'altra pratica di test importante è scrivere il test e accertarsi che non riesca almeno una volta PRIMA di scrivere il codice. È facile confondere e scrivere un test di tautologia che accidentalmente non verifica la condizione per cui si sta verificando. Le false assicurazioni sono quasi (e talvolta peggiori) delle assicurazioni.

    
risposta data 16.02.2011 - 16:49
fonte
0

Un'idea che ho usato di volta in volta è questa,

crea un ramo e rompi il codice, esegui il test e assicurati che il test rilevi l'errore.

    
risposta data 16.02.2011 - 12:53
fonte
0

Do you have certain groundrules when testing your code?

  • Metti sempre alla prova il tuo codice e cerca di raggiungere la copertura più alta possibile.

Alcuni punti generali aggiuntivi:

  • dedicare un po 'di tempo alla progettazione e alla progettazione prima di iniziare il codice
  • refactoring il tuo codice!
risposta data 23.03.2012 - 08:51
fonte

Leggi altre domande sui tag