Questo è un problema che io e il mio team affrontiamo in quasi tutti i progetti. Testare alcune parti dell'applicazione con JUnit non è facile ed è necessario iniziare presto e attenersi ad esso, ma questa non è la domanda che sto chiedendo. Il vero problema è che con n-Threads, il blocco, le possibili eccezioni all'interno dei thread e degli oggetti condivisi l'attività di testing non è semplice come testare la classe, ma testarli in infinite situazioni possibili all'interno del threading.
Per essere più precisi, lascia che ti parli del design di una delle nostre applicazioni:
Quando un utente fa una richiesta, vengono avviati diversi thread che analizzano una parte dei dati per completare l'analisi, questi thread eseguono un certo tempo a seconda della dimensione del frammento di dati (che sono infiniti e di qualità incerta) analizzare, o possono fallire se i dati erano insufficienti / carenti di qualità. Dopo aver completato ciascuna analisi, chiamano un gestore che decide dopo che ogni thread termina se i dati di analisi raccolti sono sufficienti per fornire una risposta alla richiesta.
Tutti questi analizzatori condividono alcune parti delle applicazioni (alcune parti perché le istanze sono molto grandi e solo un certo numero può essere caricato in memoria e quelle istanze sono riutilizzabili, alcune parti perché hanno una connessione permanente, dove la connessione richiede tempo, connessioni ex.gr. sql) quindi il blocco è molto comune (fatto con i blocchi di rientro). Mentre le applicazioni funzionano in modo molto efficiente e veloce, non è molto semplice testarlo in condizioni reali.
Ciò che facciamo in questo momento è testare ogni classe e le sue condizioni predefinite, ma non ci sono test automatici per l'interblocco e la sincronizzazione, il che a mio avviso non è molto buono per le assicurazioni di qualità.
Dato questo esempio, come gestiresti il test del threading, dell'interlocking e della sincronizzazione?