Come giudicare il valore dell'uso di TDD o di test di unità semplici in un progetto Open Source? C'è una buona regola empirica? [duplicare]

0

Nel mio attuale progetto OSS, non ho saputo letteralmente nulla di ciò che stavo facendo quando ho iniziato.

Mi stavo integrando con un progetto più grande come plug-in, e questo in sé e per sé aveva una curva di apprendimento ripida.

Se avessi iniziato con TDD, non sarebbe mai stato scritto poiché il mio codice stava cambiando mentre stavo imparando.

Questo ha funzionato per molto tempo. Ora ho superato il punto in cui i test unitari forniscono rendimenti negativi, e ho bisogno di scriverli. Così, mentre aggiusto le cose, per gli oggetti so come scrivere un test, lo farò.

La mia domanda, qualcuno ha una buona regola pratica su quale punto dovresti dire a te stesso - stop - i test di unità devono essere usati da qui in poi.

Credimi - non è il giorno 1. Sto cercando una risposta pragmatica. Ricorda, non guadagno nulla dal mio lavoro, mi diverto a scrivere nuove funzionalità e non nuovi test per quelli vecchi. Questa è la radice del dilemma.

    
posta sylvanaar 16.09.2013 - 19:49
fonte

2 risposte

1

No, non esiste una regola empirica.

Dipende davvero da quanto affidabile e manutenibile vuoi che sia la tua base di codice. Se il tuo progetto è una piccola classe o un'utilità one-shot, potresti non aver bisogno di nessun test unitario. Se, d'altra parte, si tratta di un framework o di un programma core che verrà utilizzato da molte persone, potrebbero essere necessari test di unità completi e probabilmente sarà necessario dall'inizio.

Il test dell'unità, se usato correttamente, guida la progettazione generale del software. Il codice verificabile è più facile da mantenere, più facile da ragionare e ha meno bug. Questo è vero sin dal primo giorno così come lo è alla fine del tuo progetto. Ritardare questo processo si basa sulla falsa idea che il test dell'unità richieda più tempo rispetto alla semplice scrittura di un'applicazione e alla verifica manuale. Mentre il test delle unità richiede un po 'più tempo per essere configurato, si ripaga da solo la prima volta che devi eseguire nuovamente i test.

A meno che tu non stia scrivendo in un linguaggio dinamico con un REPL, onestamente non vedo come ritardare i tuoi test unitari ti aiuterà. Uso i test unitari come shim per provare codice sperimentale. Quando ho un codice che funziona, io collaudo sia il test unitario che il codice di lavoro in stato "di prima classe" nel mio progetto, e il test unitario funge da prototipo di progetto per il codice effettivo, oltre a verificare che il codice sia ancora funziona dopo un refactoring.

Se sei lavora in un linguaggio dinamico con un REPL (al contrario di un linguaggio tipizzato staticamente come C #), i test unitari diventano ancora più importanti, perché non hai più la rete di sicurezza di verifica del tipo statico durante la compilazione.

Da nessuna parte questa filosofia è più evidente di quella del codice SQLite. SQLite ha circa 84 mila linee di codice di produzione, coperte da oltre 90 milioni di codice di test. Sono abbastanza sicuro che l'autore non abbia mai pensato "quindi quando dovrei iniziare a scrivere test di unità per questa cosa?"

Ulteriori letture
link

    
risposta data 16.09.2013 - 22:01
fonte
0

Test e copertura del test sono cose difficili da quantificare, non credo che la copertura del codice al 100% sia essenziale, o addirittura una buona idea, ma una buona serie di test sviluppati usando TDD o meno ti farà risparmiare tempo a lungo termine e migliorare la qualità del tuo codice.

Come regola generale: se sai davvero cosa dovrebbe fare il codice e puoi definirlo in modo chiaro ed esatto, userò TDD, ti aiuta a ridurre i requisiti ea concentrarti sulla cosa che stai sviluppando. Altrimenti se la natura esatta del codice si sta ancora formando o modificando man mano che vai, scrivi un test non appena hai una versione funzionante di cui sei soddisfatto e pensi che le firme ecc. Non siano suscettibili di modifiche.

Trovo molto più difficile testare in modo retroattivo un progetto, è più facile codificare i test quando la cosa su cui si sta lavorando è ancora fresca nella memoria.

Se il suo codice banale probabilmente non scriverebbe affatto un test.

    
risposta data 16.09.2013 - 22:08
fonte

Leggi altre domande sui tag