Come programmate efficacemente quando impiega molto tempo a testare semplicemente il vostro codice?

Il mio flusso di lavoro è sempre stato quello di scrivere un passaggio logico, quindi eseguire il programma e controllare l'output. Questo processo mi è servito incredibilmente bene per incarichi all'università. Tuttavia, poiché faccio più sviluppo, ci sono volte in cui la semplice compilazione ed esecuzione del codice richiede da 1 a 2 minuti. Gli esempi includono il caricamento di un programma su un microcontrollore, la necessità di interazione con un server esterno e l'impossibilità di implementare l'automazione a causa di autenticazione, architettura del software o complessità.

Questi tipi di attività non sono molto adatti al modo in cui di solito programma e ho difficoltà a scrivere codice in modo efficace. Di solito commetto molti errori di sintassi ed errori logici, la maggior parte dei quali riesco a cogliere facilmente dai test. Tuttavia, con un tempo di attesa così lungo, questo metodo richiede troppo tempo.

Prima di tutto, qualsiasi tipo di debug interattivo è eccezionale. Lo vuoi nel tuo toolkit, perché se non ancora, un giorno trarrai davvero beneficio dal farlo. (I dettagli variano in base a lingua, piattaforma e IDE.)

richiede interazione con un server esterno e incapace di implementare l'automazione a causa di autenticazione, architettura software o complessità.

Esaminerei alcuni framework per l'utilizzo di oggetti finti . Questi ti consentono di circondare il componente testato con un falso ecosistema di altri componenti, in modo che i tuoi test siano mirati in modo più specifico e puoi evitare di testare tutto quanto un'unità intera.

Inoltre, gli stessi oggetti simulati possono essere programmati con asserzioni, quindi è possibile verificare che il componente in fase di test abbia effettivamente effettuato una determinata chiamata.

Lavorerei sodo per ridurre i tempi di prova. Avevo lavorato in un paio di aziende sviluppando codice incorporato e i test erano dolorosi, richiedendo viaggi nella sala server e FTP manuali e riavvii e più comandi all'hardware di prova. Poi mi sono unito a un gruppo davvero valido, in cui ho semplicemente potuto digitare "make test" sulla mia scrivania e ottenere risultati in meno di un minuto. In quel minuto:

• Il mio codice è stato incorporato in una nuova immagine del kernel per l'hardware incorporato.
• Il server DHCP è stato aggiornato per puntare al nuovo kernel.
• La scheda di test è stata riavviata.
• La scheda di test ha recuperato il kernel dalla mia workstation tramite un mount NFS.
• La scheda di test è stata riavviata sul nuovo kernel.
• Sono stati eseguiti i test unitari.
• L'output del test dell'unità è stato restituito alla mia workstation.

Ci è voluto del tempo per far funzionare tutto questo, ma lo sforzo di automatizzare tutti questi passaggi è stato recuperato cento volte con la crescita del personale di sviluppo.

I test automatizzati non sostituiscono la revisione e la comprensione.

È possibile che tu stia utilizzando i test come stampella. Se lo fai, impedirai il tuo apprendimento. Non sto sostenendo che non testerai. Invece ti consiglierei che prima di eseguire il test rivedi ciò che hai scritto. Comprendi cosa hai scritto, assicurati che abbia senso e assicurati che la sintassi appaia corretta.

Hai già dato la risposta: I usually make a lot of syntax errors and logic errors

Quindi, lavorando sodo per migliorarlo, dovresti essere in grado di ridurre i tempi di test. Gli errori di sintassi dovrebbero essere i primi che dovresti ridurre. Non hai mai avuto un test di programmazione con una carta e una matita nel tuo studio?

Ho avuto la stessa cosa quando sono passato da PHP a Java. Ho dovuto imparare a eseguire il debug invece di stampare solo alcune variabili e premere F5 nel browser ...

È necessaria una buona piattaforma di test funzionale o unitaria in grado di eseguire automaticamente test per te, preferibilmente in background. Ciò richiederà l'uso di Mock come indicato sopra e in base alla lingua utilizzata per l'iniezione di dipendenza.

Rendendo i tuoi oggetti il ​​più indipendenti possibile e quindi utilizzando i metodi di iniezione per aggiungere vincoli esterni, non è difficile creare una piattaforma di test per il tuo codice.

Il vero divertimento arriva quando semplicemente non puoi testare il tuo codice se non usandolo con rabbia. Questo accade abbastanza con i sistemi di trading, poiché i simulatori di scambio disponibili sono spesso poveri, inesistenti o non conformi a ciò che dicono i fornitori del software di scambio. Questo fa parte del ricco arazzo della vita, temo. Il mio approccio è quello di assicurarmi che almeno il mio lato della transazione sia ben scritto e ben documentato, in modo che possa essere facilmente modificato rapidamente.

Test unitari; Simulazioni / simulazioni finte.

Ciò richiederà tempo, garantito, e potrebbe essere necessario raccogliere e massaggiare i dati del campione per creare modelli appropriati, ma alla fine pagheranno: ti risparmierai tutto il tempo e i problemi che incontri quando provi a testare contro sistemi.

Utilizzati correttamente, questi strumenti assicureranno che prima di andare ovunque vicino a sistemi esterni, sei sicuro al 99,9% che se il tuo codice fallisce, è qualcosa nel sistema esterno / cambiamento di ambiente che lo ha causato, non un bug nel tuo codice.

Ho lavorato professionalmente per un bel po 'come facevi a scuola, e in molti casi è stato molto efficace. Alla fine ho lavorato con alcune persone che mi hanno costretto ad abbandonare quella metodologia e ad usare invece test unitari e modelli.

Ora, non avvio alcun progetto senza prima pensare attraverso l'implementazione delle fasi di test: test unitari, modelli, simulatori, dati di esempio, ecc.

Di solito faccio molti errori di sintassi ed errori logici

Forse usare una Linter può aiutarti un po 'qui.

Ero in una situazione simile con il mio precedente datore di lavoro. La nostra base di codice era davvero enorme e per apportare eventuali modifiche al codice, compilare quindi sostituire i .classfile in un dev-server quindi riavviare lo sviluppo con lo script di riavvio. E con mio sgomento, ci vorrà circa mezz'ora per riavviare dev-server.

Successivamente ho scoperto che era anche possibile eseguire il debug remoto del dev-server.

Quindi, ecco cosa ho fatto per ottimizzare il mio processo

• Primo round iniziale di debug remoto, questo mi ha permesso di vedere l'esatto flusso di codice e gli esatti valori / stati delle variabili.

• Pianifica come e quali cambiamenti farò.

• Apportare modifiche e quindi confrontare le differenze

• Errori nella cache usando linter o compilando.

• Fornire la correzione rapida sostituendo i .classfile e riavviando.

A volte includerei anche un sacco di istruzioni di registro per controllare di nuovo il flusso del codice e per verificare la presenza di valori / stati. Questo mi ha aiutato molto.

Anche l'uso di un IDE con una buona auto-complicazione può aiutare notevolmente a ridurre gli errori di battitura.

Spero che sia di aiuto.