Qual è l'alternativa alla frequente verifica manuale?

2

Stavo pensando, c'è un momento particolare nella tua codifica in cui verifichi che funzioni? Dì, dopo aver codificato una funzione, o un'intera classe, o un'intera sezione di un'app, o dopo ogni "significativo" blocco di codice?

Chiedo questo, perché tendo a verificare la mia app troppo spesso, a volte dopo ogni 3 ° o 4 ° cambio. Questa è un'abitudine che si è dimostrata molto difficile da scuotere. Sembra controproducente eseguirlo ripetutamente e manualmente.

C'è un'altra soluzione? Sembra essere o un programmatore più competente ed essenzialmente "conoscere" il ritorno della maggior parte del tuo codice, o fare in modo che il tuo IDE controlli periodicamente il ritorno, o solo testare il rendimento tramite TDD.

    
posta Damien Roche 24.04.2012 - 19:22
fonte

4 risposte

7

Sembra che tu stia passando troppo tempo a testare manualmente la tua applicazione e dovresti provare a automatizzare questo processo con i test.

or have your IDE check the return periodically

Non c'è un modo reale per farlo se non scrivere i propri test con asserzioni auto-scritte.

Se la spedizione del codice rotto è un killer per la tua azienda e la tua applicazione ha complessità (come sembra) dovresti scrivere test per verificare il comportamento.

I test non sono una pallottola d'argento, ma renderanno il lavoro esistente molto più semplice.

or only test the return via TDD.

Va notato che non devi fare TDD per avere test automatici.

    
risposta data 24.04.2012 - 19:29
fonte
4
  • Il problema è che non hai alcuna fiducia nel tuo codice. Sì, in parte è una "cattiva abitudine", ma penso che il problema principale sia in effetti una mancanza di fiducia.

  • Alla fine lavorerai su un sistema in cui non sarai in grado di verificare immediatamente le tue modifiche. Ciò potrebbe avere un impatto negativo sulla tua produttività.

  • Per risolvere questo problema, devi impostare un obiettivo e aumentare gradualmente il bersaglio.

  • I test unitari ti aiuteranno a testare i singoli componenti, ma c'è solo molto che può essere fatto con i test unitari. Ciò diventa più rilevante nei sistemi aziendali.

  • Ogni volta che rompi qualcosa o il sistema fa qualcosa che non ti aspetti, prendi nota di cosa è successo e di come lo hai risolto. Alla fine dovresti iniziare a vedere un modello. Dovresti essere in grado di risolvere questo problema valutando le tue statistiche.

  • Suppongo anche che tu sia stato uno sviluppatore per un periodo relativamente breve di tempo, quindi la fiducia nel tuo codice aumenterà con la tua esperienza.

risposta data 24.04.2012 - 23:18
fonte
2

Crea test unitari. Se sei nella prima prova, scrivi prima il test e controlla il ritorno non appena scrivi il metodo. Se non lo sei, dovresti scrivere il test unitario il prima possibile dopo aver scritto il metodo.

In ogni caso, dovresti testare il codice prima di andare avanti.

    
risposta data 24.04.2012 - 19:31
fonte
0

Crea test unitari e automatizza i tuoi test, ma smetti anche di testare così spesso. Prendi un minuto in più per rileggere ciò che hai scritto e aumentare la tua sicurezza sul fatto che funzioni. In questo modo non ti affidi ai test unitari per cogliere gli errori più semplici e aumenti la fiducia nelle tue capacità.

Aneddoto: stavo facendo da tutor a uno studente e volevano compilare il codice e testarlo dopo aver modificato alcune righe, ho detto loro di no e abbiamo proceduto a scrivere tutto il codice che ci serviva e poi lo abbiamo testato. Prima del test, abbiamo esaminato riga per riga per assicurarci che la logica fosse corretta. Alla fine, il compilatore ha catturato solo errori ortografici e i test unitari non hanno rilevato errori.

    
risposta data 24.04.2012 - 23:54
fonte

Leggi altre domande sui tag