È pazzesco spostare la logica di distribuzione nella suite di test ...?

2

Usiamo (e amiamo) la struttura di test del jest. La maggior parte dei nostri test sono dei bei test unitari in stile codice buono-igienici compartimentati.

Tuttavia abbiamo anche scritto alcuni test di livello di servizio (impostazione di server e richieste di rilascio) e anche alcuni test di implementazione più lunghi per testare l'automazione della distribuzione dello stack. Questi sono separati in modo tale che la maggior parte delle volte esegui solo i primi test di unità, ma quando è necessario puoi invocare (o CI può) gli altri test più lunghi.

Configurare questi tipi di test di integrazione può essere complicato poiché a volte è necessario aggirare (o modificare) le limitazioni degli strumenti che si stanno utilizzando e testare, tuttavia, una volta ottenuto un buon modello, non male.

Ora che molte di queste cose sono state configurate - sto avendo questa pazza idea che forse dovrei usare il nostro framework di test per eseguire effettivamente il processo di distribuzione di produzione stesso ... In questo modo la logica di distribuzione reale più esattamente corrisponde al test di quella logica. Nella misura in cui l'implementazione effettiva comporta il concatenamento di vari componenti e strumenti, perché non esprimerlo in modo tale da consentire di sfruttare facilmente il codice proveniente dal resto del progetto. E la logica necessaria per testare correttamente le variazioni del processo di distribuzione può essere direttamente riutilizzata per eseguire realmente l'implementazione della vita reale e mantenere centralmente / verificati tutti i parametri di configurazione richiesti in un modo davvero piacevole. Inoltre, le istantanee possono essere utilizzate per affermare tutti i tipi di aspettative sull'ambiente di distribuzione e prevenire ogni sorta di fonti impreviste di variazione ...

Questa idea sembra pazzesca? Sono davvero tentato di provarlo ... Qualcuno l'ha già fatto prima?

    
posta Ben 15.08.2017 - 20:59
fonte

2 risposte

6

Vedi in questo modo: ciò che hai effettivamente fatto è che hai automatizzato i passaggi del tuo processo di distribuzione in un modo guidato dal test, proprio come puoi implementare qualsiasi altro programma o componente in questo modo. Dato che hai fatto questo in un modo "dal basso verso l'alto", come un "effetto collaterale" puoi eseguire gli elementi costitutivi della distribuzione non solo per la distribuzione reale, ma anche ai fini del test.

Semplicemente cambiando il tuo punto di vista, non sembra più così folle, suppongo?

Una cosa da considerare qui potrebbe essere, quanto è impigliata la tua distribuzione automatizzata con il tuo framework di test al momento? Se questi due sono strongmente accoppiati, potrebbe essere una buona idea disaccoppiarli, quindi per l'implementazione della produzione non è necessario necessariamente l'installazione o una conoscenza specifica del framework di test. D'altra parte, forse i due sono strongmente accoppiati ma non è un problema reale per te, quindi potresti lasciarlo così com'è.

    
risposta data 15.08.2017 - 21:13
fonte
5

Se il tuo "codice di prova" viene utilizzato per distribuire il codice di produzione, non è più il codice di prova, è il codice di produzione.

Detto questo, la tua idea è solida in quanto il mirroring del tuo ambiente di produzione nel miglior modo possibile nel tuo ambiente di test è una buona cosa. Se il tuo codice di prova contiene metodi migliori e più robusti per configurare l'ambiente di produzione (?), Ha senso esaminare anche lo spostamento del codice in produzione.

Tuttavia, non considerare questo come "distribuzione con codice di test", ma piuttosto trattarlo come "integrazione del nostro codice di test nel codice di produzione". Se non disponi di alcun tipo di gestione della configurazione o di team di distribuzione, ti suggerisco di iniziare a discutere su chi detiene anche questo pezzo della tua base di codice.

    
risposta data 15.08.2017 - 21:12
fonte

Leggi altre domande sui tag