Controllo degli strumenti di compilazione del codice sorgente e compilazione [chiuso]

Sì, l'integrazione continua è una buona pratica per qualsiasi progetto. Per progetti molto piccoli, l'infrastruttura necessaria per un'integrazione continua può essere eccessiva, ma questo non si applica ai piccoli progetti realizzati all'interno di una grande azienda: una grande azienda dovrebbe già disporre dell'infrastruttura necessaria e aggiungere un piccolo progetto non dovrebbe essere troppo difficile.

Per quanto riguarda i test unitari, devi prendere una decisione da solo:

• I progetti più grandi sono più adatti per i test delle unità rispetto a quelli più piccoli,

• I progetti business-critical sono più adatti per i test unitari rispetto ai progetti che non fanno nulla di critico,

• I progetti che seguono pratiche come la revisione del codice di tutto il nuovo codice, recensioni formali, ecc. richiedono meno test unitari di progetti che non lo sono.

Nota a margine: il fatto che tu abbia aspettato fino a quando altri sviluppatori sono stati aggiunti al tuo team prima di iniziare a usare il controllo di versione è disturbante. Dovresti utilizzare il controllo della versione per qualsiasi progetto, incluso quello in cui lavori da solo.

In breve: Sì, l'uso di build generate da un server di build e test di unità sono buone prassi per ogni progetto.

Utilizzare un server di build per generare le tue build continue e notturne ti porterà grandi benefici. Lo considererei una buona pratica per ogni progetto tra le altre pratiche di integrazione continua . Idealmente, non vi è alcuna differenza tra le build continue e notturne, ma questo dipende dalle dimensioni del progetto. Potresti pensare che il tuo computer sviluppatore funzioni già come ambiente di integrazione , che è vero e potrebbe essere sufficiente per progetti su piccola scala. Ma immagina di rivisitare il progetto di nuovo in futuro. Sarà sempre utile se il tuo ambiente di integrazione è memorizzato in alcune VM dove non interferisce con tutti gli altri progetti che hai fatto. La tua catena di strumenti è configurata correttamente in quell'ambiente e non si è rotto nulla solo perché è stato necessario aggiornare alcuni strumenti. Utilizzalo nuovamente, ogni volta che ne hai bisogno e assicurati che il progetto funzioni nell'ambiente a cui è destinato. Inoltre, avrai sempre le tue build in una volta non sparse sul tuo computer personale. Sono pronti per essere testati continuamente. Quindi questo è in qualche modo un prerequisito per testare ogni commit che a sua volta ti assicura di rilevare gli errori in anticipo.

Come per testing : un progetto così piccolo che non ha una buona architettura potrebbe essere difficile da testare, quindi la dimensione del progetto influenza la capacità di testare. Tuttavia, la maggior parte delle lingue moderne ha già un set di strumenti di test standard e ci sono alcuni principi che ti aiuta a progettare la tua applicazione in modo che sia facile da testare. Il test delle unità potrebbe essere più semplice di testare l'intero sistema, tuttavia dovresti sempre avere test di sistema che coprano i tuoi casi d'uso.

he reminded me about the concept of a compilation tool chain and specifically nightly builds for unit testing

Nightly per i test unitari ?! WTF ?! Sono cose totalmente indipendenti

Torna alle domande

Is it good practice for all software development teams to use unit testing

Si

and nightly builds?

Irrilevante e condizionale-specifico. Il test unitario implica a) automatico b) copertura completa c) test interni d) dell'intero prodotto (idealmente, con CI - dopo ogni cambio in codebase), nightly - a) controlli manuali b) con meno frequentemente c) da tester esterni d) per lo più solo alcune - ampiamente utilizzate o di recente fisse - funzionalità del prodotto

Is there any criteria that identifies teams that are more suitable than others for nightly builds.

Prodotti di massa, mirati su sistemi di profondamente diversi (che non possono essere facilmente riprodotti nell'ambiente dello sviluppatore), possono essere testati meglio dagli utenti nell'uso quotidiano

How do developers identify areas suitable for unit testing?

In ogni caso, Unit Testing deve testare tutte le operazioni, eseguite dal prodotto testando blocchi elementari di prodotto

I assume that you look at the use cases

No, è Test funzionale , dove collaudi come funziona , in Unità Test esegui più test di basso livello "Funzionerà?" "Funzionerà sempre?" "Tutti i rari casi sono stati rilevati?" etc