Test JUnit in un'applicazione multithread

5

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?

    
posta Sebastian van Wickern 05.02.2013 - 11:38
fonte

2 risposte

6

Dato che non sono mai stato davvero contento delle risposte che ho ricevuto, avevo già rinunciato e risolto i problemi di concorrenza con il tempo, ma senza test effettivi che dimostrassero che non esistevano più. Ma oggi mi sono imbattuto in una soluzione per il problema.

Collegamenti che spiegano la scrittura di questo tipo di test:

In breve, tutti questi test inizializzano Runnable e li avviano esattamente allo stesso tempo per ottenere un massimo carico di concorrenza, in questo modo dovrebbero essere esposti i problemi di concorrenza.

    
risposta data 04.06.2013 - 12:58
fonte
5

Sembra che tu stia eseguendo test di integrazione e non test di unità

In generale, quando esegui un test unitario, dividi il codice nelle sue parti più piccole e testane ciascuno separatamente. A volte, è necessario emulare le dipendenze - un processo chiamato mocking. Buone librerie di derisione includono JMockit (per fare il mocking di qualsiasi cosa, incluso rendere String mutable) o Mockito se le tue esigenze sono normali.

In questi giorni le applicazioni multithread in Java dovrebbero essere costruite sui pacchetti java.util.concurrent e avere ExecutorService nel loro cuore. A meno che i tuoi bisogni non siano molto specifici, non c'è più alcun reale requisito per accedere direttamente a Thread .

Dato un progetto basato sui pacchetti di concorrenza, dovresti essere in grado di scomporre la tua analisi e costruire test unitari isolati per loro. Questo approccio dovrebbe semplificare notevolmente il tuo codice e rendere il comportamento dei thread molto più prevedibile di quanto suoni attualmente.

    
risposta data 05.02.2013 - 18:10
fonte

Leggi altre domande sui tag