In CI, i test dovrebbero essere eseguiti contro src o dist?

Da un punto di vista del test generico:

"Test in anticipo" è un'ottimizzazione del flusso di lavoro. Ti aiuta a scorrere più velocemente fallendo rapidamente. I test che sono vicini al codice sorgente, come i test unitari, sono utili qui.

"Test in ritardo" è un requisito per la garanzia della qualità. Devi testare il codice esattamente come viene spedito, perché come hai detto, ci sono più punti in cui le cose possono andare storte anche dopo che il codice sorgente è stato convalidato. I test di alto livello che integrano più componenti sono utili qui.

Dovresti eseguire sia test di basso livello che di alto livello. Non sono sicuro del perché "presto e tardi" non è un'opzione, ma è esattamente quello che consiglierei.

In genere eseguiresti i test delle unità in anticipo: sono test degli sviluppatori che i bit che hai sviluppato funzionano come previsto in isolamento. Quindi eseguirai più tardi test di integrazione più ampi, poiché testano che i bit che hai sviluppato funzionino come previsto con gli altri bit.

Non è necessario eseguire i test unitari sia in anticipo che in ritardo - è ridondante per eseguirli in ritardo se li si esegue già in anticipo, ma non è possibile eseguire i test di integrazione in anticipo (ovviamente). CI è il posto dove eseguirli.

In generale, ogni modifica al codice dovrebbe essere testata. Esattamente come fai questi test e quali test sono fatti specifici per la situazione e l'ambiente in cui ti trovi.

Il test sia in anticipo che in ritardo sarebbe l'alternativa consigliata. Dici che alla fine sarà il caso, ma fino ad allora devi sceglierne uno sull'altro.

Sembra davvero che tu stia cercando il miglior compromesso finché la situazione non matura e consente entrambi. Scegli quello che mette alla prova la modifica più rischiosa e poi consente le correzioni più rapide al codice - dai suoni di esso, questo è il test anticipato per ora. Se il QA viene eseguito dopo tutto questo, ti offre un'ultima opportunità per individuare i problemi.

Come già accennato, il collaudo precoce dei test unitari identifica gli errori logici e aiuta a correggerli prima di procedere all'integrazione. Una volta in integrazione, il test identifica in ritardo problemi di integrazione e compatibilità. Offre anche test del sistema finale e test di accettazione degli utenti.

Dato che stai usando CI, è molto probabile che sia comunque un ambiente altamente automatizzato, usalo, automatizza quanti più test possibili. Questo ti dà un maggiore livello di sicurezza che non stai introducendo problemi di regressione. Sono felice che tu abbia identificato la causa del perché non puoi fare entrambe le cose, il sistema di ticketing dovrebbe supportare la rapida consegna del codice di qualità, non inibirlo.

Grazie per le risposte. Sono sorpreso dalla misura in cui le persone pensano che "fallire velocemente" sia importante all'interno della CI. C'è una differenza tra il ciclo di sviluppo (individuale) e il ciclo di integrazione (squadra).

sviluppo

Uno sviluppatore fa una piccola modifica. Esegue i test per garantire che il cambiamento non abbia infranto nulla. Se qualcosa si rompe, lo sviluppatore controlla il codice, nota un errore, lo corregge ed esegue nuovamente i test. Quel ciclo può letteralmente accadere un paio di volte al minuto, a condizione che i test siano in grado di funzionare quasi istantaneamente. Se sono necessari alcuni minuti per l'esecuzione dei test, si spegnerà il tempo di ciclo e si interromperà il flusso di lavoro dello sviluppatore.

Integrazione

Uno sviluppatore unisce una modifica. La generazione viene eseguita e qualcosa non riesce. L'intera squadra viene informata del fallimento. Il team comunica per capire chi lavorerà al problema. Un paio di sviluppatori mettono insieme le loro idee, tirano giù l'ultimo codice, eseguono la build localmente, capiscono cosa è andato storto, fanno una modifica, impegnano il codice con un messaggio di commit premuroso, spingono il codice sul server e si uniscono. Potrebbero esserci altri passaggi che richiedono tempo. Questo è generalmente il minimo indispensabile.

In questo caso, se ci vuole qualche minuto in più per scoprire un errore (la differenza tra "early" e "late") non ha molto impatto sul tempo di ciclo complessivo.

Se scegli di non eseguire test sul prodotto finale durante l'IC, e qualcosa sul processo di concatenazione / minificazione causa l'introduzione di un bug, potrebbero essere ore, giorni o addirittura mesi prima che il bug venga scoperto.

Eseguire i test "presto" in CI è un "bello avere". L'impatto sul tempo di ciclo complessivo è marginale. Eseguire i test "in ritardo" è un "must have". Non riuscire a farlo può essere catastrofico.