Il tempo di esecuzione di un test unitario è utile per qualcosa? Un unit test è un luogo appropriato per qualsiasi tipo di profiling del codice? Perché o perché no?
Caso di utilizzo del campione :
Come potrei usare queste informazioni?
Una delle regole più importanti sui test unitari è che dovrebbero eseguire veloce .
Gli sviluppatori dovrebbero essere in grado di eseguire l'intera suite di test unitari in pochi secondi, e sicuramente non in minuti e minuti. Gli sviluppatori dovrebbero essere in grado di eseguirli rapidamente dopo aver modificato il codice in ogni caso. Se impiega troppo tempo, non si preoccuperanno di eseguirli e perderai uno dei principali vantaggi dei test. Al momento abbiamo circa 800 test eseguiti in circa 30 secondi.
Quindi se qualche test inizia a richiedere troppo tempo, puoi vedere quale test impiega troppo tempo e fare qualcosa al riguardo.
Il nostro framework di test unitario ci dice quanto tempo è occorso per ogni test da eseguire. La maggior parte di essi richiede da 0 a 5 ms (se non ricordo male), ne abbiamo uno o due che richiedono circa 3 secondi.
Is the execution time of a unit test useful for anything?
Sì.
Is a unit test an appropriate place for any sort of code profiling?
Sì.
Why?
Perché hai bisogno di fatti e misurazioni. Se una suite di test è lenta, è importante sapere dove è possibile concentrarsi, separatamente, sul perché.
Il profiling del codice viene eseguito solo quando il codice risulta essere lento.
I test unitari sono un modo semplice, economico, ovvio, indolore per individuare (1) codice lento e (2) cambiamenti improvvisi nelle prestazioni.
Considera lo sviluppo dei tuoi requisiti non funzionali:
Requisito funzionale: una volta che i filtri sono stati selezionati, il rapporto dovrebbe essere generato. Non funzionale: il rapporto dovrebbe essere generato in 2 secondi.
Se il tempo di esecuzione del test è > 2 secondi, potresti addirittura fallire il test come test di "usabilità".
Posso solo pensare ai test di temporizzazione se nel codice testato potrebbe verificarsi qualcosa come un ciclo infinito.
Se si eseguono i test unitari come parte delle verifiche post-commit o di una build, la macchina che la gestisce può avere tutti i tipi di carichi che rendono inutili i test a tempo. Esegui tali test prestazionali (non test unitari ) in un ambiente controllato.
Può essere utile raccogliere statistiche sui tempi di esecuzione del test per prevedere i tempi di esecuzione di grandi suite di test (server di integrazione, come TeamCity, fare questo).
Potrebbe essere utile se si dovesse tenere traccia delle prestazioni medie per un dato test in tutte le esecuzioni di test. Un improvviso aumento dei tempi di esecuzione potrebbe segnalare l'introduzione di un nuovo collo di bottiglia nel codice.
Inoltre, in generale, è auspicabile mantenere l'esecuzione per un intero set di test unitari il più rapidamente possibile, al fine di incoraggiare il frequente svolgimento dei test. Conoscere l'esecuzione di test individuali ti aiuterà a identificare quali test richiedono più tempo in tutti i test.
Potrebbe essere utile se stai testando una procedura che è nota per essere lenta. Potresti scrivere test unitari che testano la procedura con input di dimensioni diverse e potresti monitorare le prestazioni di quel pezzo di codice. Ovviamente, indipendentemente dal fatto che questo sia applicabile nel tuo progetto dipende davvero dal tuo progetto. Io uso quando è facile determinare quale funzione ha un collo di bottiglia, e vogliamo isolare e testare solo quella funzione.
Leggi altre domande sui tag unit-testing profiling