Sto avendo una perdita di memoria quando si esegue una suite di test a causa della creazione di oggetti Singleton e non dopo ogni caso di test. E questi oggetti singleton contengono riferimenti a oggetti pesanti.
Quindi non so se esiste una soluzione migliore della cancellazione degli oggetti singleton nei metodi tearDown() in ogni classe di test!
Che ne pensi?
tipicamente, questo significa che il singleton ha superato la sua intenzione originale e dovrebbe essere reso un oggetto standard (leggi: non un singleton).
la testabilità è uno dei motivi principali. i dolori che aggiornano i programmi per utilizzare più istanze sono un altro. ancora un altro: spesso è un collo di bottiglia difficile all'esecuzione. il modello singleton è spesso abusato, utilizzato per le ragioni sbagliate e porta a problemi (come questo).
quindi, di solito fai in modo che l'oggetto non funzioni più come un singleton o astratti i suoi veri dati esclusivi condivisi (se presenti) dietro l'interfaccia di qualche classe. questa sequenza di dati condivisa e init / destroy indica che si tratta di un singleton per le ragioni sbagliate o che è cresciuto per fornire troppe funzionalità.
per quanto riguarda gli oggetti pesanti: puoi creare inizializzatori / costruttori per supportare questo utilizzo: ObjectWithMovie(movie)
Se hai assolutamente bisogno (spesso per ragioni storiche, a meno che il tuo team continui a scrivere singleton) un grosso blob di stato globale mutabile (che è la somma attuale dei singleton e degli altri stati globali del tuo programma), preferisco fare una classe per mantenere questi - allora il titolare è l'unico singleton e responsabile dell'inizializzazione / distruzione. allora la complessità del tuo stato globale condiviso diventa più ovvia (casualmente, la ragione per cui a molte persone non piace farlo).
comunque, il singleton è difficile da testare e da quello che ho visto, la maggior parte degli usi sono stati resi singletons senza una buona ragione - questo diventa solo un dolore quando è necessario testare, riutilizzare, estendere eccetera.
quindi puoi eseguire felicemente tutti i tuoi test (in parallelo) senza elaborate sequenze di avvio / interruzione.
buona fortuna
So I don't know if there is a better solution than clearing the singleton objects in the tearDown() methods in each test class!!
Sbarazzati dei singleton. I singleton sono difficili da testare comunque (stato globale). Utilizzare invece l'iniezione di dipendenza. Simula oggetti pesanti con oggetti leggeri se sei ancora nei guai.
Se davvero non riesci a sbarazzarti di quei singleton, prova a "cancellarli" dopo ogni test. Il "clear" non deve necessariamente essere nel metodo tearDown() , sebbene sia un buon posto per tali compiti.