Di solito ci sono due motivi per preoccuparsi delle prestazioni / test di carico, o il team ha difficoltà a scrivere algoritmi semplici o specifici requisiti di prestazione fanno parte di uno SLA. La terza ragione è che i membri della tua squadra si preoccupano solo delle prestazioni, ovvero l'ottimizzazione prematura.
I test delle prestazioni non dovrebbero mai far parte del test dell'unità. I test unitari sono, per definizione, per testare la correttezza dell'unità; Bubble Sort e Quick Sort sono entrambe implementazioni valide per un requisito di ordinamento. Anche se si dispone di un requisito di prestazioni, tale requisito non sarà sull'unità ma su una porzione verticale del sistema. Supponendo che il collo di bottiglia per essere questa unità sta assumendo troppo. E se i tuoi test unitari impiegano troppo tempo a correre (idealmente meno di un secondo, mai più di 10) diventano inutili; gli sviluppatori iniziano a eseguirli meno frequentemente, non lo fanno affatto, o smettono di scrivere test. Che lascia due opzioni.
Rendi i tuoi test delle prestazioni parte della pipeline di implementazione. I test delle prestazioni vengono eseguiti dopo i test di unità e integrazione come parte di ogni commit (o qualsiasi altra azione attiva la pipeline). Saranno eseguiti sul tuo manufatto costruito. Percorri questa strada se un SLA richiede determinate caratteristiche prestazionali o se hai problemi a discutere sulla qualità del codice del tuo team ("Ogni volta che Jimmy fa un commit porta i server in ginocchio sotto un carico pesante e passiamo giorni a risolvere il problema!" ).
Esegui i test delle prestazioni durante la notte. I test delle prestazioni sono programmati per essere eseguiti a una determinata ora del giorno. Questo è positivo quando i test di prestazioni / carico richiedono molto tempo. Forse sei passato per la prima strada, ma questi test stanno diventando un collo di bottiglia da rilasciare con la frequenza che desideri. Ora che hai preso l'abitudine di eseguirli più frequentemente forse il tuo team è migliorato nella scrittura di semplici algoritmi. Forse ora puoi suddividere i tuoi test di carico in "test assolutamente necessari prima di implementare in produzione" e "test che ci tengono in buona forma ma i problemi con loro non aumentano di molto".
Potrebbe essere, come ha detto Doc Brown, che i test delle prestazioni durano una settimana. Ma questo è un caso limite che ti lascerò capire quando esci. Riporta qui con i risultati.
L'esecuzione di test delle prestazioni come parte della fase di test di integrazione non sembra corretta. I test delle prestazioni e del carico sono generalmente utilizzati per rintracciare i problemi con una porzione verticale della vostra applicazione in modo da avere un'indicazione su dove immergersi. Non ci sarebbe molto valore per prendere in giro i servizi in quanto le prestazioni sono una bestia volubile. Questi servizi risponderanno in modo diverso sotto carichi diversi. Tuttavia, potrebbero esserci alcuni endpoint di terze parti in cui non potrebbero fornire una sandbox per te. Forse puoi prendere il tempo di risposta della produzione e spegnerlo in modo appropriato. Il tempo di risposta potrebbe anche essere automatizzato con l'arrivo di nuovi dati ogni giorno.
Non ci sarà una taglia unica e sospetto che mentre andrai avanti ti imbatterai in una nuova soluzione.