Miglioramenti nel framework di test basato su java per ridurre i tempi di esecuzione

Quindi la soluzione che abbiamo trovato è questa. Dockizzeremo il pacchetto di test in modo da avere più contenitori che eseguono più server e più code di messaggi. Utilizzeremo i profili Maven per distribuire la stessa guerra, ma eseguiremo diversi test pack nei contenitori separati. Il pacchetto di test sarebbe modularizzato in modo tale che i test all'interno di ciascun modulo non si sovrappongano l'un l'altro in termini di code / messaggi. Grazie a tutti per il loro tempo e i loro preziosi commenti.

Esistono filtri sulle code di messaggi. È possibile inserirli nella stessa coda di messaggi e quindi assegnare un listener per i messaggi in base a un criterio specifico. Questo criterio può essere qualsiasi cosa, per collegare ID a un nome di messaggio arbitrario.

Il risultato finale è che i messaggi che non hanno quel criterio specifico non vengono buttati via, semplicemente aspettano di essere processati dai gestori senza tali criteri, consentendo in pratica di eseguire controlli su aspetti specifici relativi a messaggi specifici senza rimuovere messaggi altri rispetto a quelli che desideri controllare.

Una delle cose che mi faceva impazzire era quando eclipse avrebbe eseguito i miei test in parallelo quando non me l'ero aspettato. Questo mi ha irritato perché sono un tester di vecchia scuola che pensa ancora che scrivere alla console sia utile. Due test avrebbero scritto sulla console e, a volte, tutto andava bene. A volte il testo di un utente viene mixato a metà strada tra gli altri.

Poi ho capito quanto fosse semplice la soluzione. Lascia che ogni test costruisca la propria stringa e restituisca quella stringa alla volta. Una volta fatto ciò, ho potuto lasciare che i test funzionassero parallelamente bene.

Se non hai dipendenze sequenziali, memoria condivisa o uscite multiple da ogni lavoro da mantenere in ordine, non vedo perché non puoi lasciarle funzionare in parallelo.

Since there is only 1 queue on which the test pack asserts the output message, we have to clear the queue each time before we run the next test case. Otherwise it may lead to mixing of the output messages. For e.g. method call#2 might end up consuming output message for method call#1. Hence we can't run the test cases in parallel too.

Assegna id univoci ai messaggi e ascolta il messaggio con l'ID previsto nella coda di output con un limite di tempo superiore. Questo dovrebbe farti provare le esecuzioni parallele.

Puoi racchiudere questa logica di pubblicazione / ascolto in un'implementazione generica di stile di richiesta / risposta. Da lì in poi, usa qualcosa come RxJava per comporre scenari di più di tali chiamate.