Con algoritmi randomizzati in un ambiente CI è della massima importanza che il risultato del test sia il più non casuale possibile. Devi in ogni caso trovare un modo per garantire che un'implementazione corretta quasi sempre porti ad un test superato. In caso contrario, tu o i tuoi colleghi sarete costretti a disabilitare il test e pianificate di riscriverlo. Non è possibile bloccare l'intero downstream a causa di un errore casuale del test. Inoltre, non è accettabile dover ricostruire "perché a volte semplicemente non funziona".
Pertanto, è possibile e non si devono scrivere test che coinvolgono un algoritmo con un risultato casuale, ma provare a verificare un risultato concreto. Come ha sottolineato Robert Harvey, l'unico modo significativo per affrontare la qualità di una distribuzione casuale è analizzarlo in modo matematico / statistico. Per quanto in profondità tu entri in quella tana del coniglio, è una questione di preferenze personali e l'importanza e la precisione richiesta dell'unità sottoposta a test.
Potresti provare a misurare valori come deviazioni standard se il tuo campione è abbastanza grande. Si potrebbe anche optare per un approccio più pratico, ad esempio, assicurandosi che un certo numero di immagini diverse venga visualizzato all'interno delle viste X. Per quanto riguarda quest'ultimo, è comunque necessario tenere presente che è necessario formulare un criterio, per il quale la probabilità che venga violato da un'implementazione corretta a causa di una variazione casuale è estremamente ridotta. Preferibilmente, dovrebbe essere inferiore alla probabilità che l'hardware del server CI non funzioni correttamente.
Quando scrivi i test effettivi, ci sono in genere due cose da tenere a mente con casualità:
-
Seed. Come già detto da Robert Harvey, puoi rendere la vita più facile a te stesso quando sai quale seme ha causato il fallimento. La casualità è davvero difficile da "riprodurre" altrimenti. Non consiglio comunque di usare un seme fisso. Dovresti prendere un seme fresco per ogni ciclo, perché vuoi che il tuo algoritmo sia testato da CI su un sacco di valori diversi nel tempo. Ma dovresti fare attenzione, che i messaggi di fallimento del test contengano qualsiasi seme utilizzato.
-
Prestazioni. Se stai scrivendo i test BDD per i criteri di accettazione, potrebbe non essere un grosso problema. Se includi tali test all'interno dei test unitari, sarà molto più lento rispetto ad altri test a causa delle ripetute corse richieste. Alcuni libri sostengono che un test unitario dovrebbe essere più veloce di 10 ms. Questo è praticamente impossibile se si tenta di eseguire un algoritmo randomizzato 1000 volte. 10 ms possono sembrare estremi, ma una volta che si desidera eseguire centinaia di migliaia di questi test, questo si riassume rapidamente, ancor più quando sono necessarie ripetute esecuzioni.