Nei nostri test automatici Java, a volte incontriamo problemi, come ad esempio:

• Test A crea un file personalizzato A.sh , che viene quindi aggiunto al classpath
• La pulizia automatizzata di testsuite non conosce il file casuale A.sh , e non lo pulisce
• Test Z fallisce perché succede che A.sh non ha influenza su tutti gli altri test ma causa un errore in questo particolare test

Questi problemi sono incredibilmente difficili da debugare e da seguire, perché test A potrebbe essere stato scritto 3 anni fa da persone che se ne sono andate 2.5 anni fa. Mi chiedo, come implementereste un controllo robusto e performante di più file?

Ho in mente un seguente flusso di lavoro:

• Prima del test: salva lo stato di tutti i file nella directory controllata. Si noti che il numero di file che ci interessa veramente è ~ 30 in circa 2-3 directory.
• Durante il test: il test li modifica comunque.
• Dopo il test: la suite di test verifica lo stato di tutte le configurazioni. Se lo stato corrisponde allo stato precedente a Test, procediamo. Altrimenti, lo riportiamo al suo stato originale.

Nella mia mente, questo è simile a:

• git add . && git commit -m "Original state"
• Test modifica qualunque cosa sia necessaria
• git reset --hard && git clean -fd

Sono quasi tentato di usare letteralmente git per questo, cioè inizializzare il repository con lo stato originale e quindi semplicemente resettare lo stato. C'è un modo migliore?

Allo stato attuale, attualmente copiamo tutti i file di configurazione prima di testsuite (lo stato originale) e dopo ogni test, li copiamo indietro (ripristina lo stato originale), indipendentemente da quali configurazioni sono cambiate. Questo soffre di:

1. Essere lento perché tutte le configurazioni sono scritte sul disco indipendentemente da quali file sono stati usati
2. Principalmente, se c'è un nuovo file per il quale non abbiamo tenuto conto, poiché si tratta di un file personalizzato che non viene fornito con il server, la suite di test non è in grado di rimuovere il file.

C'è qualche soluzione elegante a questo problema che consiglieresti? Sta usando git qualcosa che potrebbe farmi rintracciare 5 anni dopo quando non sono più in compagnia, con un'ascia per macinare?

Altre possibili soluzioni:

• Creare un piccolo DB in cui salvare tutti i file con hashsum all'inizio di una suite di test e controllare tutti i file sul DB?
  • Se gli hashs corrispondono, non ci preoccupiamo.
  • Se l'hashsum non è stato trovato nel DB ma il nome è, ripristinalo
  • Altrimenti, cancellalo

La mia preoccupazione è quanto performante sarebbe, anche se stiamo parlando di DB in memoria, potrebbe andare bene. Inoltre, un'altra mia preoccupazione sarebbe che questa potrebbe essere la parte più fragile della suite di test. Dopotutto, i test dovrebbero essere il più indipendenti possibile.

Si noti che usiamo una suite di test per un massimo di 5 versioni del nostro software, quindi l'insieme di ~ 30 file e ~ 2 directory differisce, e quindi deve essere in qualche modo memorizzato nella cache / ricordato all'inizio di ogni sparo della suite di test.

Vincoli

• Stiamo parlando solo di testuite. Non posso apportare modifiche al numero di file di configurazione che dobbiamo guardare
• Stiamo parlando di eseguire la suite di test su più architetture; la soluzione al minimo molto deve essere disponibile per Linux, Windows e Solaris (quindi Java)
• Usare una lingua diversa da Java è OK, ma deve essere molto ben motivato. Non mi interessa scrivere la soluzione in un piccolo piccolo binario C separato e compilarlo a croce, ma questo aggiunge una grande quantità di complessità e, in quanto tale, non è una decisione da prendere alla leggera.