I test di unità automatizzati dovrebbero far parte della build?

Dichiarazione di non responsabilità: non sono un purista riguardo ai test. Mi piace fare il mio TDD, ma non credo che la copertura al 100% sia necessaria per tutti i progetti.

Detto questo, la regola generale dovrebbe essere " ogni modifica deve essere testata e approvata prima di andare in produzione ".

Ciò significa che è possibile eseguire i test dopo il commit (attivati automaticamente dallo strumento di integrazione continua, come Jenkins, TFS o altri) o durante la fase di pre-distribuzione della build.

Personalmente, trovo noioso eseguire test per ogni singola build che faccio sulla mia macchina e renderli facilmente "derapati" ad altre faccende mentre i test sono in esecuzione.

Detto questo, nessun codice che va in produzione viene direttamente dalla mia macchina, tutti vanno da una macchina CI / Build. Ciò garantisce che nessuno del mio codice ha il timbro "Funziona solo sulla mia macchina".

Se disponi di un team di grandi dimensioni, il test dopo il commit potrebbe essere una strategia migliore, per consentirti di identificare tempestivamente gli interruttori e consentire al team di recuperare e comunicare più rapidamente, ma probabilmente avrà bisogno di più risorse del server per farlo.

Con un team più piccolo e ben oliato, test di pre-distribuzione su UAT / Produzione può essere sufficiente per garantire la qualità.

Tieni presente alcune regole pratiche:

• Il codice non cifrato è codice non esistente;
• Il codice non testato non dovrebbe andare in produzione;
• La tua macchina non dovrebbe produrre le build, dovrebbe un server di integrazione di CI.

Should automated unit tests be a part of the build process, or should they be manually run when someone makes changes to the code instead?

Entrambi.

Gli UnitTests sono una rete di sicurezza per entrambi, lo singolo sviluppatore e il processo di integrazione .

Lo sviluppatore individuale verifica eseguendo gli UnitTests che il codice che ha scritto implementa realmente il comportamento desiderato e non interrompe il comportamento desiderato già esistente.

Il processo di integrazione verifica eseguendo gli UnitTest che l'unione di percorsi di sviluppo diversi non ha inficiato alcun comportamento desiderato.

Rendili un obiettivo di build diverso: make unit . In questo modo, spetta allo sviluppatore decidere se lo sviluppatore vuole solo la compilazione o anche i test unitari. Assicurati di avere il meccanismo per eseguire test unitari solo per un dato sottomodulo, perché potrebbe non avere senso eseguire tutti i test unitari continuamente.

Come parte della tua build di integrazione continua (Jenkins o simile), esegui anche tutti i test unitari. E eseguirli in una modalità in cui un errore non ferma il resto dei test. Tuttavia, make unit può fermarsi al primo errore.

Dico, se i test dell'unità richiedono meno di 1-2 secondi per essere eseguiti, fallo. Altrimenti no. Costruire la tua applicazione non dovrebbe mai richiedere un IMO lungo, perché perdi l'attenzione ogni volta che devi costruire.

La tua build dovrebbe fallire se i tuoi test unitari non passano. Questo rafforzerà la qualità. A che serve una build in cui alcune funzionalità non funzionano come previsto?

Inoltre, ti impedisce di dimenticare di eseguire i test di unità. Oppure ti impedisce di saltare volontariamente i test il venerdì alle 5 del mattino.

Sì. : D Ma non esiste una risposta valida per tutti.

Tuttavia, un'autentica automazione dei test rileva sempre più problemi prima rispetto ai test unitari ad hoc, salvandoti da problemi più estesi. E, ricorda, se non stai costruendo per la pubblicazione, stai costruendo per testare le tue ultime modifiche, vero?

A seconda delle dimensioni del tuo progetto, dovresti scegliere di eseguire tutti i test unitari come parte della build privata, se il tempo aggiunto è trascurabile. Ma aggiungere più di 10 a una build da 1 minuto o da 2 a una build da 1 secondo non è probabilmente una buona idea. In tal caso, potresti voler identificare uno o due test unitari rapidi che effettuano un test di integrità della funzionalità più importante che esegui su ogni build privata.

Tuttavia, non appena si dispone di un build-server che è in grado di eseguire il pull da VCS, è necessario aggiungere la funzionalità per eseguire "tutti" i test unitari ogni volta che viene prodotta una nuova build di successo. A meno che "tutto" impieghi troppo tempo, cioè ... Si riduce al numero di build / giorno, al tempo medio di costruzione e al test unitario. Man mano che il progetto cresce, scoprirai che dovrai rendere la compilazione modulare abbastanza da non dover testare unitamente parti non codificate del code-base.

E non importa quanto intelligenti progettiate i vostri casi di test, troverete inevitabilmente un caso d'uso importante che veramente deve impiegare molto tempo, sia che si tratti di elaborazione intensiva o semplicemente di bisogno di tempo reale per tick. Quindi, per quei casi avrai bisogno anche di invocazione condizionale o manuale.