Quanta ottimizzazione dovresti inserire per le configurazioni lente di test di integrazione

Naviga le tue risposte
1

Ho alcuni test di integrazione molto lenti che usano Selenium e richiedono molte impostazioni del database. I tempi di setup e di smontaggio sono nell'ordine di decine di secondi mentre i corpi del test impiegano solo pochi secondi ciascuno. Dato che ci sono centinaia di questi test, questo si aggiunge molto.

Il mio posto precedente ha un elaborato sistema di pooling / riutilizzo delle risorse che identifica quali finestre del browser / tabelle del database sono in uno stato "buono" e le riutilizza invece di ricreare. Questo riduce il tempo di setup / demolizione a quasi 0 per test (quando nessun test fallisce)!

Ho trascorso alcuni giorni a fare una versione semplificata del codice di riutilizzo del browser Selenium e questo ha prodotto ottimi risultati. Tuttavia, il codice di manutenzione del database sarebbe molto più difficile (ad esempio, la mia vecchia posizione utilizza Hibernate per ricreare lo schema, che non posso usare qui). Stimo che ci vorrebbe almeno una settimana di lavoro, ma dal momento che il tempo risparmiato è solo in CI, trovo difficile mettere il mio manager a bordo. Credo che una svolta più rapida aiuterebbe anche lo sviluppo dei test quotidiani, ma a nessuno sembra importare.

Mi chiedo quanto tempo le persone normalmente spendono per l'ottimizzazione del test di integrazione lento, specialmente in piccoli gruppi (3-4 persone). E in che modo le persone giustificano un'ottimizzazione coinvolta come sopra?

Modifica:

Un po 'più dettagli sui costi: i test di integrazione vengono eseguiti su scatole Jenkins condivise durante la notte. Richiedono 1-2 ore a seconda di quanti test falliscono e quanto è occupato il box del database condiviso.

Li usiamo principalmente per i test di regressione. Il passaggio è un requisito per l'approvazione dell'uscita; tuttavia, la gestione consente di rilasciare correzioni / hotfix minori con solo i test di integrazione unità e non Selenium più veloci.

Conosco due casi nell'ultimo anno che sono stati rilasciati bug che sarebbero stati catturati dai test del selenio. Speravo di poterlo eliminare completando i test entro un periodo di tempo.

Inoltre, è possibile risparmiare un po 'di tempo di sviluppo poiché ogni esecuzione manuale di un particolare test sarà più veloce. Ma un calcolo del back-of-the-envelope mostra il tempo trascorso in attesa che i test eseguano account di almeno l'1% del tempo di sviluppo, quindi probabilmente non vale la pena di ottimizzare ulteriormente ...

    
posta billc.cn 14.03.2016 - 13:03
fonte

2 risposte

3

Scopri il costo.

Hai un sacco di vecchie macchine che stai utilizzando per questo che non hai realmente bisogno? È molto più economico che se si debbano acquistare nuove macchine per renderle più veloci.

O il tuo sistema CI è su github / amazon o da qualche parte stai pagando direttamente i costi per il servizio? Quanto costano all'anno questo?

Questo impedisce al tuo team di lavorare (1 vs 5 minuti è una differenza molto piccola, ma 30 minuti contro 5 ore è molto più significativo) fermando il tuo flusso di lavoro affinché CI possa essere eseguito?

Una volta capito questo, calcola quanto ti costerà per risolverlo - stimare quante ore ci vorrebbe (e quindi probabilmente moltiplicare per 2 o 3 dato che la tua stima sarà quasi sicuramente bassa). Se il vantaggio è migliore del costo ... sarà facile da vendere. Se no ... beh, qual è il punto?

    
risposta data 14.03.2016 - 13:51
fonte
0

Scrivere test, data esperienza, dovrebbe essere molto facile. Quando i test diventano difficili da implementare o gestire, tende a essere un indicatore di un problema più grande indipendentemente dal test. È il tuo spunto per ascoltare ciò che i test ti dicono e avere un ripensamento.

Hai trascorso alcuni giorni a lavorare sull'automazione dei test. A quale guadagno? A un certo punto, dovrai recuperare quel tempo. Sei sicuro che questo renderà la tua azienda più produttiva a lungo termine?

Questo è in parte il motivo per cui alcune persone si riferiscono a test di integrazione come Vortex Of Doom . Odio pre-giudicare ciò che potrebbe rendere l'inizializzazione del test così lento, ma immagino che potrebbero esserci molti dati che devono essere configurati, indicando molta interdipendenza e parti del sistema che sanno o stanno facendo troppo .

Hai dei test unitari di buona qualità? Perché non investire il tuo tempo in una progettazione basata su test di buona qualità basata su test mirati? Un buon approccio TDD assicurerà che il tuo sistema non sia così complesso da richiedere un sacco di configurazione, oltre a fornirti un set di test di regressione molto più snello.

In risposta alla tua domanda, non perderei tempo nell'ottimizzare i test di integrazione lenti, dato che non riavrai mai più quel tempo. Potrebbe persino permetterti di scavare un buco più profondo senza rendertene conto. Vorrei dedicare questo tempo al refactoring del codice di produzione per ridurre la necessità di grandi quantità di setup, rendendo a sua volta più semplice il codice di produzione. Nel tempo, vorrei evitare i test di integrazione e i test mirati.

    
risposta data 14.03.2016 - 13:28
fonte

Leggi altre domande sui tag

Implementazione file-directory: un file deve possedere un riferimento alla sua dir? I migliori modi in cui le startup possono gestire le informazioni sensibili degli utenti [chiuso]