Come migliorare il test del proprio codice [chiuso]

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

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

Quindi, ora vi sto chiedendo ragazzi: avete determinate regole di base durante il test del codice?

Scrivi i test prima di apportare modifiche al codice.

Se la modifica proposta è quella di correggere un bug, far fallire inizialmente il test dimostrando il bug. Quindi assicurati che passi dopo aver corretto il bug. Se in seguito scrivi il test e lo hai mai visto passare, non puoi essere sicuro di aver testato correttamente il bug in primo luogo.

Se la modifica proposta è quella di modificare la funzionalità esistente o aggiungere una funzionalità, scrivere alcuni test per garantire una buona copertura dell'area di codice che si intende modificare. Assicurati che questi test superino prima di iniziare a modificare il codice e comunque al termine.

Non dimenticare di testare i casi limite! Molti bug sono dovuti al fatto che l'azione più comune è stata testata ma non quella meno comune.

Seguire i consigli tecnici nelle risposte orientate tecnicamente; è roba buona. La mia risposta riguarda più l'atteggiamento.

Sentirsi male nel fare il tipo di errore che ogni sviluppatore commette occasionalmente è semplicemente assurdo e non ti aiuta a non fare quel tipo di errore in futuro. Mentre ti siedi lì a sentirti male, la build è ancora rotta, sai? E poi il tuo lavoro è tutto incentrato sull'evitare errori, che so rendere alzarsi dal letto la mattina un'avventura emozionante ogni giorno, giusto?

Ho sentito parlare di aziende in cui il check in di codice non funzionante è causa di vergogna pubblica. Non riesco nemmeno a smettere di pensare a quel tipo di pensiero distorto, fratellastro, di livello junior che porterebbe a un simile comportamento. Difficilmente ci potrebbe essere QUALCOSA di più controproducente da fare per un capofila o un manager.

Quindi non ti picchiare. L'abbiamo fatto tutti. Probabilmente mi costa mezza giornata alla settimana in errori sciocchi, e lo faccio da molto tempo. Ecco come sembra scrivere codice: ti stai costantemente scontrando con quelle che sembrano le tue inadeguatezze. Ciò che rende un professionista un professionista non è una qualità mitica che non commette mai errori (anche a volte grandi), ma il modo in cui RISPONDONO agli errori che commettono.

Se c'è un mantra che posso instillare in ogni sviluppatore con cui lavoro, è questo: non sei il tuo codice . Scrivi il codice. Lo scrivi nel modo più efficiente ed efficiente possibile. Poi vai a casa. Se identifichi il tuo valore o autostima come persona con la qualità del tuo codice, ti stai perdendo la barca su chi sei veramente.

Un'altra importante pratica di test è quella di scrivere il test e assicurarsi che fallisca almeno una volta PRIMA di scrivere il codice. È facile sbagliare e scrivere un test di tautologia che per sbaglio non verifica la condizione che si sta verificando. Le false assicurazioni sono quasi (e talvolta peggiori) di nessuna assicurazione.

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

creare un ramo e rompere il codice, eseguire il test e assicurarsi che il test rilevi l'errore.

Hai alcune basi durante il test del tuo codice?

• Testare sempre l'unità del codice e cercare di raggiungere la massima copertura possibile.

Alcuni punti generali aggiuntivi:

• investire un po 'di tempo in progettazione e progettazione prima di iniziare a programmare
• refactoring il tuo codice!